11 | 使用ZooKeeper实现分布式锁-ZooKeeper实战与源码剖析-极客时间

公平锁会有一个比较麻烦的地方，比如节点1获得了锁，节点2客户端watch节点1，节点3客户端watch节点2。此时如果节点2的客户端心跳失效，触发watch机制，节点3的客户端要更换watch节点，也就是watch锁持有者节点1，否则一旦节点1释放锁，其它客户端永远感知不到。而非公平锁，不会存在这个问题，中间其它未持有锁的client端的session失效，并不会对其他客户端产生影响，另外我们日常工作的大部分场景的锁竞争并不会特别激烈，所以非公平锁的性能会更佳，正因为如此，jdk下JUC包里面的锁类默认都是采用非公平模式

作者回复: 分布式锁这么设计的原因是为了避免羊群效应，公平性是一个副作用。这样设计是有你说的那个问题。

2019-10-17

3

5

老师，这个znode是不是就是类似redis中的一个key的概念呢。另外我们这边经常用redis来做分布式锁（setnx命令），只是redis没有将请求者进行排队，感觉redis要简单一些，能否点评一下这两种锁的使用场景及优缺点。

作者回复: > 老师，这个znode是不是就是类似redis中的一个key的概念呢你可以把znode理解成Redis的一个key。但是znode之间有层次关系。 > 另外我们这边经常用redis来做分布式锁（setnx命令），只是redis没有将请求者进行排队，感觉redis要简单一些，能否点评一下这两种锁的使用场景及优缺点。 1. 如果一个调用setnx的Redis客户端crash，它设置的key还会存在，换言之锁不会自动释放。在ZooKeeper里面，我们用临时节点表示锁，如果ZooKeeper客户端crash，它的锁会自动释放。 2. ZooKeeper实现的锁可以在锁释放时只通知一个锁请求者，还保证锁分配的FIFO。个人感觉ZooKeeper的锁方案更加完备。setnx只是一个简单的SET if Not eXists命令，如果你的场景很简单也可以用它。另外Redis(https://redis.io/commands/setnx)本身也不推荐使用setnx了。 > The following pattern is discouraged in favor of the Redlock algorithm which is only a bit more complex to implement, but offers better guarantees and is fault tolerant.

2019-08-27

3

5

钱

zk分布式锁的高性能是怎么保证的？

作者回复: 分布式锁性能保证的关键点是避免herd effect。本节的实现是保证锁释放的时候，只有一个锁请求者收到通知。

2020-02-21



3

Douglas

老师分布式锁的场景，创建的是临时节点，如果T1 请求获得锁后，执行业务逻辑，这个时候如果业务还没执行完，网络原因导致了 session过期，session过期，临时节点会被服务器删除，这时其他节点也可以获取锁，分布式锁就被破坏了，这个场景如何来解决呢？

作者回复: 您的场景可以创建持久性节点。

2020-02-21

3

3

北海以北

老师，是不是zookeeper没有加锁的功能，而是客户端自行做逻辑判断它如果不是排在第一位，则不能获取资源呢？

作者回复: 是的，ZooKeeper本身不提供锁，但是可以使用znode操作来实现。但是实现出来的锁也是advisory的，这就是说用户可以忽视这个锁直接获取资源。 Chubby的锁机制也是advisory的。

2019-09-01



2

legendtkl

如果 node 是按数字序号作为后缀，是不是意味着数字序号会被用完？

作者回复: 一个目录下的顺序性节点是统一进行编号的，用的是int类型。如果一个目录下面有超过2^32个顺序性节点的话，会有您说的问题。但是这种情况实际发生的概率很小，所以ZooKeeper没有针对这种情况做处理。

2019-10-06



1

请问一下老师课程中讲的代码是zk的代码还是zk客户端的代码，我有点晕

作者回复: zookeeper的源代码。https://github.com/apache/zookeeper/tree/branch-3.5.5/zookeeper-recipes/zookeeper-recipes-lock

2019-08-27

3

1

滩涂曳尾

老师，之所以不用一个znode来实现分布式锁，主要就是为了防止羊群效应吗

2021-01-24



1

长脖子树

感觉还是文字版要清晰, 使用zookeeper创建分布式锁的过程如下: 1. create EPHEMERAL_SEQUENTIAL 节点 /lock/xxx-0000000003 2. 获取所有已经创建的子节点, 但不注册 watcher /lock/xxx-0000000001 /lock/xxx-0000000002 /lock/xxx-0000000003 3. 如果发现自己是最小的那个, 则客户端已经获得了锁 4. 如果不是最小的, 则通过调用 exists() 前一个节点 /lock/xxx-0000000002, 并注册 watcher 5. 当 watcher 收到前一个节点(/lock/xxx-0000000002) node delete 事件时, 则说明自己获取了锁

2020-07-15

1

1

dream

老师，请问一下，java程序与zk连接 close() 后，在服务器使用 netstat 查看 2181 端口会有一个 TIME_WAIT 的连接，但是过一段时间，这个连接就没有了，能说一下这是什么原因吗？

2020-06-18

1



收起评论