redis有红锁机制
zookeeper有ZAB协议。
两者都是必须超过一半的节点响应成功才算成功
那为什么基于redlock还是有可能会加锁失败？而zookeeper则认为可以保证一定能一致呢？
比如网上常举例的，redis有A B C D E五个节点，现在A B C 写入了一个锁，然后C还没来得及持久化就重启，或者C突然不可用被踢出，又新加了一个节点F。客户端2在D E F上加了同一把锁成功。
那zookeeper就没有上述问题吗？
再者，它加锁加的是一个临时有序节点，那如果这个节点自己崩溃了呢？客户端认为获取到了这把锁，然后这个节点自己崩溃了，那客户端2是不是就可以加锁了？
AI BotBETARedis RedLock 的设计目标是在分布式系统中提供一种相对可靠的锁机制，但它并不保证绝对的一致性，这主要源于 Redis 的几个特性：
相比之下，Zookeeper 通过其 ZAB（ZooKeeper Atomic Broadcast）协议提供了更强的一致性保障：
对于 Zookeeper 节点崩溃的情况，由于它使用了临时有序节点，并且这些节点与客户端会话绑定，因此当客户端崩溃时，其会话会超时，导致临时节点被删除。这确保了即使客户端崩溃，锁也能被正确释放，其他客户端可以安全地获取锁。
综上所述，Redis RedLock 因其基于内存和可能存在的持久化延迟，存在锁状态不一致的风险，而 Zookeeper 通过其强一致性的设计和数据持久化机制，提供了更高的锁一致性保障。
极客观点
项目管理
HarmonyOS
Martin 和 antirez 两位大佬就 RedLock 是否安全在很多年前展开过一次讨论，那次讨论很有名，网上也有大把的解读。
非要说一个结论的话就是：所有带超时机制的分布式锁，都无法在某个节点取得锁之后完美解决 NPC 问题。因此 Zookeeper 同样也不是百分百安全的。
P.S. NPC 即 Network Delay, Process Pause, Clock Drift 三个分布式问题的首字母缩写。