- 标清
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.5x
ZooKeeper实战与源码剖析
精选留言(6)
2019-08-27老师，这个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. 2
2019-12-17老师，如果使用curator框架进行分布式锁的实现（针对并发修改表中的一条记录），
InterProcessMutex lock = new InterProcessMutex(client, lockPath);
故我对表中的id字段进行加锁，但是这个id不能放在上面的lockPath中，否则在zookeeper中就会产生成千上万个znode。所以，这个id必须是临时节点，但是InterProcessMutex中好像没有找到相应的api，是否只能走zookeeper原生的方式实现吗展开
2019-10-17公平锁会有一个比较麻烦的地方，比如 节点1获得了锁，节点2客户端watch节点1，节点3客户端watch节点2。此时如果节点2的客户端心跳失效，触发watch机制，节点3的客户端要更换watch节点，也就是watch锁持有者节点1，否则一旦节点1释放锁，其它客户端永远感知不到。
而非公平锁，不会存在这个问题，中间其它未持有锁的client端的session失效，并不会对其他客户端产生影响，另外我们日常工作的大部分场景的锁竞争并不会特别激烈，所以非公平锁的性能会更佳，正因为如此，jdk下JUC包里面的锁类默认都是采用非公平模式展开作者回复: 分布式锁这么设计的原因是为了避免羊群效应，公平性是一个副作用。这样设计是有你说的那个问题。
2019-10-06如果 node 是按数字序号作为后缀，是不是意味着数字序号会被用完？作者回复: 一个目录下的顺序性节点是统一进行编号的，用的是int类型。如果一个目录下面有超过2^32个顺序性节点的话，会有您说的问题。但是这种情况实际发生的概率很小，所以ZooKeeper没有针对这种情况做处理。
2019-09-01老师，是不是zookeeper没有加锁的功能，而是客户端自行做逻辑判断它如果不是排在第一位，则不能获取资源呢？作者回复: 是的，ZooKeeper本身不提供锁，但是可以使用znode操作来实现。但是实现出来的锁也是advisory的，这就是说用户可以忽视这个锁直接获取资源。
Chubby的锁机制也是advisory的。
2019-08-27请问一下老师课程中讲的代码是zk的代码还是zk客户端的代码，我有点晕作者回复: zookeeper的源代码。https://github.com/apache/zookeeper/tree/branch-3.5.5/zookeeper-recipes/zookeeper-recipes-lock