分布式锁工具

一、背景

当前问题：项目中会使用到分布式锁用于定时任务、接口幂等性处理，但是分布式锁的实现较简单，会出现执行超时、加解锁失败等场景。分布式锁都有哪些实现，他们的优劣势是什么呢？

二、现有技术

分布式锁实现目的如下图：

1.reids分布式锁实现

1. 第一种直接通过redis提供的setNx命令执行加锁，可以设置value值。不能设置锁的有效期，如果不调用del命令，会一直存在。
2. 第二种通过lua脚本执行加锁。可以直接使用set命令进行加锁，然后设置锁的有效期，也可以使用hashSet方式，将所有的锁都保存在同一个hash数组中，通过hash中的key值进行区分，缺点是在redis中hash类型key值有效期是针对整个hashKey的。

以上两种方式都能完成加锁操作，第二种能够自由设置锁的有效期。

基于jimdb的加锁实现方式比较如下

1. jimdb事务方式：批量传入多个命令后，不间断的执行传入的命令，但不保证原子性
2. pipeline方式：批量传入多个命令后，与其他请求竞争后执行命令，不保证原子性
3. lua脚本方式：批量传入多个命令后，原子性的执行
4. set命令，jimdb直接支持setEx命令，可以在设置锁的同时设置锁的有效期，不支持重入

为什么不能先执行setNx，然后在执行expire命令，这样第一种也有有效期了呢？两个命令分开执行不具有原子性，比如加锁成功了，但在执行expire命令时失败了，还是不具有有效期。

优缺点：

1. 缺点：即使设置有效期成功了，如果操作共享资源的时间大于过期时间，就会出现锁提前过期的问题，进而导致分布式锁直接失效。如果锁的超时时间设置过长，加过期时间与不加没有了区别。
2. 优点：通过lua脚本可以实现原子性

2.redisson实现方式

需要手动初始化RedissonLock，然后进行lock操作，内部通过lua脚本的方式进行加锁，方法结束后再finally中进行unlock解锁。如果加锁时不指定过期时间，会自动续期。加锁失败会自动重试

缺点：1.目前redisson未解决redLock问题 2.redisson未解决执行超时情况 3.仅支持redis

3.zookeeper分布式锁实现

ZooKeeper 分布式锁是基于临时顺序节点和Watcher（事件监听器）实现的。

• 临时节点：临时节点的生命周期是与客户端会话（session）绑定的，会话消失则节点消失。并且，临时节点只能做叶子节点，不能创建子节点。
• Watcher事件监听：是 ZooKeeper 中的一个很重要的特性。ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。

获取锁：

1. 首先要有一个持久节点/locks，客户端获取锁就是在locks下创建临时顺序节点。
2. 假设客户端 1 创建了/locks/lock1节点，创建成功之后，会判断 lock1是否是 /locks 下最小的子节点。
3. 如果 lock1是最小的子节点，则获取锁成功。否则，获取锁失败。
4. 如果获取锁失败，则说明有其他的客户端已经成功获取锁。客户端 1 并不会不停地循环去尝试加锁，而是在前一个节点比如/locks/lock0上注册一个事件监听器。这个监听器的作用是当前一个节点释放锁之后通知客户端 1（避免无效自旋），这样客户端 1 就加锁成功了。

释放锁：

1. 成功获取锁的客户端在执行完业务流程之后，会将对应的子节点删除。
2. 成功获取锁的客户端在出现故障之后，对应的子节点由于是临时顺序节点，也会被自动删除，避免了锁无法被释放。
3. 事件监听器监听的就是这个子节点删除事件，子节点删除就意味着锁被释放。

优缺点：性能是唯一缺点，另外仅需要分布式锁功能而搭建zooker集群是不划算的。

4.数据库分布式锁

在数据库中增加一张锁表。

1. 简单：每次加锁时，插入一条数据，解锁时删除数据。
2. 使用悲观锁。通过for update增加悲观锁。
3. 使用乐观锁，表中增加版本号的概念。

优点：不需要额外部署外部服务

缺点：数据库的各种实现方式均有一些问题，通用的缺点就是性能不高，同时为数据库带来很大压力。在实现可重入、自动解锁、自动重试加锁等功能上均比较复杂。写主读从架构上，悲观锁还要考虑主从同步问题。

5.ETCD分布式锁

1.什么是etcd？

etcd 是一个分布式可靠的键值存储，用于存储分布式系统中最重要的数据，重点在于：

• 简单：定义明确、面向用户的 API（gRPC）
• 安全：自动 TLS，带有可选的客户端证书身份验证
• 快速：基准速度为 10,000 次写入/秒
• 可靠：使用 Raft 分布式协议

etcd 用 Go 编写，使用Raft共识算法来管理高可用性复制日志。

etcd 特性：

• 租约机制：用于支撑异常情况下的锁自动释放能力。可以自由设置过期时间
• 前缀和 Revision 机制：用于支撑公平获取锁和排队等待的能力，通过前缀和获取，通过revision进行顺序执行
• 监听机制：用于支撑抢锁能力
• 集群模式：用于支撑锁服务的高可用

2.如何用etcd实现分布式锁？

优点：通过raft协议保证一致性，防止脑裂，惊群效应，自带续期功能，性能高，高可用。

缺点： 吞吐量低（相比redis）。公司提供etcd集群使用，但是之前出现过购物车开天窗问题，集团不允许在高负载情况下请求直接打到etcd，所以这是唯一缺点。

6.分布式锁横向对比

三、分布式锁工具结论

方案：以上对比可知，在较低低吞度量场景下，etcd的实现方式是最好的

四、参考资料

1. redis官方文档：Distributed Locks with Redis | Docs
2. 分布式锁中的王者方案 - Redisson_redis_悟空聊架构_InfoQ写作社区
3. Redis 分布式锁｜从青铜到钻石的五种演进方案 - 悟空聊架构的个人空间 - OSCHINA - 中文开源技术交流社区
4. jimdb支持命令：https://cf.jd.com/pages/viewpage.action?pageId=584518003
5. jimdb帮助文档：登录JoySpace
6. jimdb事务:事务 — Redis 设计与实现
7. redisson:https://github.com/redisson/redisson/wiki
8. etcd：GitHub - etcd-io/etcd: Distributed reliable key-value store for the most critical data of a distributed system
9. etcd实现分布式锁：https://www.51cto.com/article/722138.html

关于redLock：

1. How to do distributed locking — Martin Kleppmann’s blog
2. Is Redlock safe? - <antirez>
3. http://zhangtielei.com/posts/blog-redlock-reasoning.html、基于Redis的分布式锁到底安全吗（下）？ - 铁蕾的个人博客 对于第一个和第二个的中文翻译和总结。。