利用redis和zookeeper实现分布式锁

为何需要分布式锁

简单来说，就是互斥的行为跨了节点，原来的进程间互斥就不起作用了。
比如说，两个节点A和B，都想修改节点C上面的文件，那么这时就需要分布式锁。

整体思想

无论是利用redis还是利用zookeeper，整体思想都是在真正做这件事情之前，去试图加一下锁，这个行为和单节点的加锁解锁是没有区别的。只不过试图加锁这个行为在分布式的情况下变得不一样了。

利用redis实现分布式锁

整体思想就是所有试图修改或读取的操作都在redis client上完成，而这些client的任何操作都是要发送到redis server上面的。因此所有的操作都会汇聚到一个节点先进行获取锁或者加锁的操作。
推荐文章：
https://www.cnblogs.com/cmyxn/p/9047848.htm
简单来说，redis利用了所有client操作均发送到一个server上，然后再server上去判断是否存在一个key的值，如果存在，就循环等待。不存在，就获取锁成功。并且给这个key设置了超时时间避免死锁。

利用zookeeper实现分布式锁

整体思想是与redis类似，就是去zookeeper去查询某个路径下面的znode的序号。也是把client的操作首先汇聚到了zookeeper上，确切的说是zookeeper的leader上面

推荐文章：
https://www.jianshu.com/p/a974eec257e6
所有的读写操作均会在zookeeper上的某个路径下面建立一个序号顺序增加的znode。然后根据读写的不同特性，如果是读请求，只要前面没有写，就可以执行，对于写请求，如果不是最小，就要等。为了避免羊群效应，还需要进行改进，在watch的时候只关和自己有关的znode的变化情况。对于读操作，只关心离自己最近的写操作的znoe，对于写操作，只关心序号最小的vnode