Redisson和Zookeeper实现的分布式锁

获取锁成功后会另开一个线程进行监控

redisson实现的分布式锁是可重入的

因为他保存了线程id可以以此去判断是不是同一个线程在获取锁，是的话就可以把重入次数+1

这个分布式锁是解决不了主从模式下，主节点挂了以后导致的数据不一致问题的。可以使用红锁来解决不一致问题，建立多个主节点当获取锁成功的数量n/2+1及以上才算获取锁成功。但这种红锁性能太低一般不被使用。

ZooKeeper 实现分布式锁的经典方案：顺序临时节点
加锁过程
创建锁节点：
客户端尝试在指定的锁目录下（例如 /locks/my_lock）创建一个临时顺序节点。
假设 ZooKeeper 生成的实际节点名为 /locks/my_lock/_lock_000000001。
检查自己是否是最小节点：
客户端获取 /locks/my_lock 目录下所有的子节点，并按节点序号排序。
如果自己创建的节点是序号最小的那个，则成功获取锁。
监听前一个节点（如果自己不是最小）：
如果自己不是最小节点，客户端就找到比自己序号小的前一个节点。
对这个前一个节点设置 Watcher 监听。
然后进入等待，不再轮询。
等待锁释放：
当前一个节点被删除（即锁被释放）时，ZooKeeper 会通过 Watcher 通知当前客户端。
客户端被唤醒后，回到第 2 步，重新检查自己是否变成了最小节点。

我觉得就是一个排队，创建节点后看自己是不是最小，不是最小就监听前一个节点，是最小就获取锁成功，锁释放以后，zookeeper会通过Watcher通知当前客户端。