Frank的私人司机

如何理解Redis RedLock的潜在失败场景与Zookeeper的锁一致性保障？

redis有红锁机制 zookeeper有ZAB协议。 两者都是必须超过一半的节点响应成功才算成功 那为什么基于redlock还是有可能会加锁失败？而zookeeper则认为可以保证一定能一致呢？ 比如网上常举例的，redis有A B C D E五个节点，现在A B C 写入了一个锁，然后C还没来得及持久化就重启，或者C突然不可用被踢出，又新加了一个节点F。客户端2在D E F上加了同一把锁成功。 那zookeeper就没有上述问题吗？ 再者，它加锁加的是一个临时有序节点，那如果这个节点自己崩溃了呢？客户端认为获取到了这把锁，然后这个节点自己崩溃了，那客户端2是不是就可以加锁了？

通了顺畅了

Redisson锁续期失败怎么通知主线程？

Redisson的看门狗实现中，对于续期失败的异常处理就是释放锁： "image.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/images/20241201/a81ddf4ba05f88cc5b7d751556b14536.png) «见红框» 也就是说主线程不会知道当前锁是否还有效，可能锁因为续期失败已经过期了，但主线程还在处理业务。 这种情况应该怎么处理呢？