zookeeper实现分布式锁

否

创建临时顺序节点

等待

之所以进行此步判断，而不是直接在监听N-1节点后直接进入等待状态，是考虑到在监听的瞬间，节点被删除了，这样就会陷入无线等待的情况

通知

执行业务代码

是

结束

判断N节点是否是最小节点

开始

为什么N-1节点被删除后，不直接获取锁进行业务执行？考虑到客户端可能会存在宕机的可能。客户端宕机则连接断开，连接断开后会话失效会导致临时节点删除，此时删除节点的下一个节点监听到删除事件后，可能就会要获取到锁执行业务了。但是此时可能正常删除的节点的顺位节点的顺序在异常删除节点之前。此时如果因为客户端宕机导致的节点删除的顺位节点获得锁，就会出现问题。因为不是最小节点获得的锁。所以需要重新排序，判断是否是最小节点。并且如果不重新排序的话，在异常删除节点的顺位节点不是最小节点的情况下，会存在多个线程获取到锁的情况。

删除节点

N-1节点是否删除

监听N-1节点删除事件

获取锁

并发线程

对所有节点排序