5. 实现分布式锁

虽然curator包都实现好了，但还是要讲讲原理

一、独占锁

多个客户端同时去创建一个同名的临时znode，谁先抢到谁就占有锁。

没有抢到锁的客户端可以通过watch去监听这个znode，以便于下次再抢锁。

二、共享锁

利用临时有序znode去实现共享锁（读锁）。

需要先明确znode命名前缀

• 读请求: xxx-Read-序号
• 写请求: xxx-Write-序号

当有写请求时，创建znode，此时如果他不是序号最小的znode，那么他就自己前面的znode。当前面的znode释放后，获取锁，就可以处理写请求逻辑。

当有读请求时，创建znode，此时如果自己是序号最小的，或是比自己序号小的都是"xxx-Read-序号"的读请求znode，那么只是就相当于获取了锁，可执行读请求逻辑。

三、与redis分布式锁有什么区别

优点：

• 不用担心续期的问题。zk依赖于临时znode，临时znode的生命周期依赖于客户端的会话，而不是像redis那样的过期时间，所以不用担心分布式锁过期续期的问题
• 比redis可靠。zk是cp架构，基于ZAB原子广播等手段保证了各节点数据的一致性，不会出现多个客户端重复获取同一把独占锁的情况。而redis是ap，无法保证各节点数据的一致性
• 效率高，开销低。基于watch通知机制，当有锁释放时通知其它监听的客户端，不用像redis那样通过频繁的轮询去抢占锁。

缺点：

• zk并发量比不上redis。如果业务量比较大的话zk会撑不住