三种使用分布式锁方案

使用mysql数据库实现分布式锁

设置数据库

CREATE TABLE `distributed_lock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `type` varchar(64) NOT NULL COMMENT '锁定的类型，包括方法，代码段等，需要给一个唯一性的命名',
  `status` varchar(16) NOT NULL DEFAULT 'off' COMMENT '锁状态，off表示关闭锁，on表示获取锁',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息，包括获取锁的服务器基本信息，业务信息等',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_type` (`type`) USING BTREE 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='';

根据业务分布情况，使用锁的业务尽量做到精简，因此，可以提供两种方案：

1.在数据初始化阶段就设置分布式锁

基于这种情况，需要在数据初始化时初始化数据，基本实现方案如下，

1）初始化分布式锁

INSERT INTO distributed_lock(type, status, desc) VALUES ( 'add', 'off', '测试分布式锁方法名');

2）重置锁

使用定时器方案，如果超时时间超过一段时间时，使用此方案进行重置锁，该方案可以开启定时任务执行

update distributed_lock set status = 'on',update_time= now() where status = 'off' and type = 'add'

3）抢占锁

update distributed_lock set status = 'on',update_time= now() where status = 'off' and type = 'add'

4）释放锁

update distributed_lock set status = 'off',update_time= now() where status = 'on' and type = 'add'

此方案可以保证锁的有效性，而且能够在前端有效的维护分布式锁

2.在锁开始使用时才设置分布式锁

1）抢占锁

每次都插入数据，当插入数据成功时，说明已经抢占到锁，如果不成功，说明没有抢占到锁，该操作由type的唯一性约束控制

update distributed_lock set status = 'on',update_time= now() where status = 'off' and type = 'add'

2）释放锁

delete from distributed_lock where type='add'

3) 重置锁

该方案也是通过定时器实现，如果超过超时时间，则进行删除锁操作，有效的防止死锁和活锁的问题

delete from distributed_lock where type='add'

 

其他更好的实现

参考：https://blog.csdn.net/lmb55/article/details/78495629

使用zookeeper实现分布式锁

zookeeper分布式锁应用了临时顺序节点

获取锁

首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。

之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。

这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。 

Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。

于是，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。

这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock3。 

 

Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最小的。

于是，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。

这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的AQS（AbstractQueuedSynchronizer）。

获得锁的过程大致就是这样，那么Zookeeper如何释放锁呢？

释放锁的过程很简单，只需要释放对应的子节点就好。

释放锁

释放锁分为两种情况：

1.任务完成，客户端显示释放

当任务完成时，Client1会显示调用删除节点Lock1的指令。

 

2.任务执行过程中，客户端崩溃

获得锁的Client1在任务执行过程中，如果Duang的一声崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。 

 

由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。 

 

同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Client3就会接到通知。 

 

最终，Client3成功得到了锁。 

参考：https://mp.weixin.qq.com/s/u8QDlrDj3Rl1YjY4TyKMCA

使用redis实现分布式锁

加锁：使用redis命令 set key value NX EX max-lock-time 实现加锁

Jedis jedis = new Jedis("127.0.0.1", 6379);
private static final String SUCCESS = "OK";

 /**
  * 加锁操作
  * @param key 锁标识
  * @param value 客户端标识
  * @param timeOut 过期时间
  */
 public Boolean lock(String key,String value,Long timeOut){
     String var1 = jedis.set(key,value,"NX","EX",timeOut);
     if(LOCK_SUCCESS.equals(var1)){
         return true;
     }
     return false;
 }

解读：

• 加锁操作：jedis.set(key,value,"NX","EX",timeOut)【保证加锁的原子操作】
• key就是redis的key值作为锁的标识，value在这里作为客户端的标识，只有key-value都比配才有删除锁的权利【保证安全性】
• 通过timeOut设置过期时间保证不会出现死锁【避免死锁】
• NX：只有这个key不存才的时候才会进行操作，if not exists；
• EX：设置key的过期时间为秒，具体时间由第5个参数决定，过期时间设置的合理有效期需要根据业务具体决定，总的原则是任务执行time*3

解锁：使用redis命令 EVAL 实现解锁

Jedis jedis = new Jedis("127.0.0.1", 6379);
private static final String SUCCESS = "OK";
 /**
  * 加锁操作
  * @param key 锁标识
  * @param value 客户端标识
  * @param timeOut 过期时间
  */
 public Boolean lock(String key,String value,Long timeOut){
     String var1 = jedis.set(key,value,"NX","EX",timeOut);
     if(LOCK_SUCCESS.equals(var1)){
         return true;
     }
     return false;
 }

解读:

• luaScript 这个字符串是个lua脚本，代表的意思是如果根据key拿到的value跟传入的value相同就执行del，否则就返回0【保证安全性】

• jedis.eval(String,list,list);这个命令就是去执行lua脚本，KEYS的集合就是第二个参数，ARGV的集合就是第三参数【保证解锁的原子操作】

重试

上面那只是讲了加锁与解锁的操作，试想一下如果在业务中去拿锁如果没有拿到是应该阻塞着一直等待还是直接返回，这个问题其实可以写一个重试机制，根据重试次数和重试时间做一个循环去拿锁，当然这个重试的次数和时间设多少合适，是需要根据自身业务去衡量的。

/**
 * 重试机制
 * @param key 锁标识
 * @param value 客户端标识
 * @param timeOut 过期时间
 * @param retry 重试次数
 * @param sleepTime 重试间隔时间
 * @return
 */
public Boolean lockRetry(String key,String value,Long timeOut,Integer retry,Long sleepTime){
    Boolean flag = false;
    try {
        for (int i=0;i<retry;i++){
            flag = lock(key,value,timeOut); 
            if(flag){
                break; 
            } 
            Thread.sleep(sleepTime); 
        } 
    }catch (Exception e){ 
        e.printStackTrace(); 
    } 
    return flag; 
}