# LockDemo

**Repository Path**: tanjunchen/LockDemo

## Basic Information

- **Project Name**: LockDemo
- **Description**: 数据库 redis zookkeeper 分布式锁的案例
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2019-07-18
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README


# 基于数据库实现的分布式锁
 ##锁表的sql语句
CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
  `mydesc` varchar(1024) NOT NULL COMMENT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


这把锁依赖数据库的可用性，如果数据库是一个单点，一旦挂掉，会导致业务系统不可用
这把锁没有失效时间，一旦解锁操作失败，会导致锁一直存留在数据库中，其它线程无法获得锁
这把锁只能是非阻塞的，因为数据的insert操作一旦插入失败就直接报错，没有获得锁的线程不会进入排队队列，想要再次获得锁就要再次触发获得锁的操作
这把锁是非重入的，同一线程在没有释放锁之前无法再次获得该锁，因为表中数据已经存在了


单点问题，两个数据库，双向同步，一旦挂掉切换到另一个上
失效时间，做一个定时任务，每隔多长时间清理超时数据
非阻塞问题，程序写for循环多次尝试，直至获取到锁为止
非重入，增加一个字段，记录获取锁的ip跟线程信息，下次查询的时候如果有，则直接给锁




# 基于redis实现分布式锁

锁的失效时间难以把握，过短业务没处理完就失效了，造成多个业务竞争资源，可能会失去锁应有的作用，过长会导致其它锁盲目等待，导致锁的性能较低，
经验来看，一般为单线程处理业务时长的2-3倍较合适。
可能出现锁失效的问题，比如某个线程执行时间特别长，超出了有效期，别的线程也会抢到锁，可能造成锁失效。
在redis集群中不太适合，因为是基于master节点的，master节点挂掉的时候如果数据没有同步到salve中，那么会造成锁失效。