三种使用分布式锁方案

使用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 实现加锁

标签：status,方案,lock,Client2,Lock1,三种,type,节点,分布式
来源： https://www.cnblogs.com/wangzxblog/p/11149372.html