分布式锁选型方案，Redisson和zookeeper curator 做分布式锁的优缺点

Redisson

1. Redisson框架集成以后，可以指定一个keykey，通过lua脚本向redis加锁。
2. 加锁后，将会启动一个“看门狗”的后台线程，定时检测是否仍然持有锁，如果持有，将延长锁的持有时间
3. 其他需要获取该锁的服务，将不断循环获取该锁，直到前面的线程释放了锁为止。

优点：

• redis性能很高，适合高并发下的加锁机制

缺点：

• 如果加锁的redis master 故障，刚好数据也还没有同步到slave，那其他加锁的客户端则会再次加锁成功，则相当于有两个客户大都拿到了锁。

zookeeper

一般会使用curator框架实现

1. 第一个客户端发起申请锁，判断是否为第一个临时顺序节点，如果是，则加锁成功。
2. 其他客户端按顺序创建后续的节点，判断是否为第一个节点，如果不是，加锁失败。同时对上一个节点进行监听，如果上一个节点被删除（释放锁），则会反向通知该客户端来获取锁。这里不能都监听第一个节点等待释放锁，因为如果都监听第一个节点，该节点一旦释放锁，则会全部通知监听该节点的客户端，引起不必要大量的网络开销，也就是羊群效应

基于zk通过创建临时顺序节点监听机制，可以反向通知客户端重新获取锁，是目前非常规范分布式锁解决方案，实时性也非常好。
但是zk加锁也会有一个问题，那就是假如说客户端1加锁成功后，由于网络原因，暂时无法收到心跳，则zk会判断改客户端已经死亡，会主动释放改顺序节点，并通知下一个客户端来获取锁，也就会造成有两个客户端同时拿到锁。这就类似于因为网络原因，造成有两个master的脑裂是同样的问题。

综上：分布式锁，使用zk会更专业，但是如果需要高并发处理，则redis会更合适。