1. Zookeeper 非公平锁/公平锁/共享锁
2. Leader 选举在分布式场景中的应用
3. Spring Cloud Zookeeper注册中心
Zookeeper分布式锁
Zookeeper 分布式锁加锁原理
![](https://i-blog.csdnimg.cn/blog_migrate/4921e8b9df4a7ed32db8defb9279baae.png)
如上实现方式在并发问题比较严重的情况下,性能会下降的比较厉害,主要原因是,所有的连接
都在对同一个节点进行监听,当服务器检测到删除事件时,要通知所有的连接,所有的连接同时
收到事件,再次并发竞争,这就是
羊群效应
。这种加锁方式是
非公平锁
的具体实现:如何避免
呢,我们看下面这种方式。
![](https://i-blog.csdnimg.cn/blog_migrate/7888101c8e22fbcbe3e8b4976b4adab7.png)
如上借助于临时顺序节点,可以避免同时多个节点的并发竞争锁,缓解了服务端压力。这种实
现方式所有加锁请求都进行排队加锁,是
公平锁
的具体实现。
前面这两种加锁方式有一个共同的特质,就是都是
互斥锁
,同一时间只能有一个请求占用,如果
是大量的并发上来,性能是会急剧下降的,所有的请求都得加锁,那是不是真的所有的请求都需
要加锁呢?答案是否定的,比如如果数据没有进行任何修改的话,是不需要加锁的,但是如果读
数据的请求还没读完,这个时候来了一个写请求,怎么办呢?有人已经在读数据了,这个时候是
不能写数据的,不然数据就不正确了。直到前面读锁全部释放掉以后,写请求才能执行,所以需
要给这个读请求加一个标识(读锁),让写请求知道,这个时候是不能修改数据的。不然数据就
不一致了。如果已经有人在写数据了,再来一个请求写数据,也是不允许的,这样也会导致数据
的不一致,所以所有的写请求,都需要加一个写锁,是为了避免同时对共享数据进行写操作。
举个例子
1、读写并发不一致
![](https://i-blog.csdnimg.cn/blog_migrate/b03e206f14e17fc6a4ce8ce78e61ccca.png)
2、双写不一致情况
Zookeeper 共享锁实现原理