zookeeper 分布式锁

先来看下zk的 watch机制

 

假设 zk 有一个 /xxoo/abc 的节点 

1. 客户端获取 /xxoo/abc 节点
2. 客户端 watch /xxoo/abc 节点
3. /xxoo/abc 节点有事件到达 会回调 客户端

思考 client可以通过定时心跳监听 /xxoo/abc 节点的变化，会有什么缺点？

1. 客户端自己实现代码
2. /xxoo/abc节点变化的时效性 ，延迟

zk实现分布式锁

1. 争抢锁，只有一个客户端能获取锁
2. 获取锁的客户端挂了，会出现死锁；采用临时顺序节点（session），client挂了，session消失，锁释放。
3. 锁被释放、删除，别的客户端怎么知道的？

• a、主动轮询、心跳。 弊端：延迟、压力
• b、watch 解决延迟 。弊端：zk需要callback所有客户端，压力大
• c、sequence + watch ，watch前一个 sequence最小的，最小的获取锁成功。一旦最小的释放锁。成本：zk只给第二个 callback。