为何需要分布式锁
简单来说,就是互斥的行为跨了节点,原来的进程间互斥就不起作用了。
比如说,两个节点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