ZooKeeper与Consul分布式锁

一、ZooKeeper分布式锁核心要点1. 实现原理临时顺序节点Ephemeral Sequential Node每个客户端尝试获取锁时在指定目录如/locks下创建一个临时顺序节点。节点名称由ZooKeeper自动添加顺序编号如/locks/lock_0000000001。客户端会话结束时如断开连接临时节点会被自动删除避免死锁。最小节点获取锁创建节点后客户端获取父目录下所有子节点并按序号排序。如果自己创建的节点是序号最小的则成功获取锁。否则客户端需要监听Watch前一个序号节点的删除事件。监听机制Watch未获得锁的客户端监听它前一个节点的删除事件。前一个节点释放锁被删除后ZooKeeper会通知当前客户端。客户端被通知后重新检查自己是否变为最小节点是则获取锁。2. 核心特性与优势强一致性基于ZAB协议保证数据强一致锁状态在集群内立即可见。避免死锁临时节点在客户端会话失效时自动删除锁自动释放。公平锁基于顺序节点严格按申请顺序获取锁实现公平性。可重入性可通过在节点数据中记录客户端标识和重入次数来实现。3. 常见面试问题羊群效应Herd Effect当锁释放时所有等待的客户端都会被唤醒同时竞争可能造成ZooKeeper服务端压力。优化方案是只让后一个节点监听前一个节点。会话超时Session Timeout网络波动可能导致会话超时临时节点被删除锁意外释放。业务处理时间应远小于会话超时时间且需实现锁的续期如使用Curator的InterProcessMutex。性能写操作创建、删除节点需要集群多数节点确认性能低于基于内存的Redis锁但强一致性保证更高。4. 常用客户端CuratorNetflix开源的高阶客户端提供了InterProcessMutex等现成的分布式锁实现解决了重入、续期等问题。二、Consul分布式锁核心要点1. 实现原理基于Key/Value存储和SessionConsul通过其KV存储和Session机制实现锁。客户端创建一个SessionSession与客户端的健康检查绑定。如果客户端失效Session会失效关联的锁会自动释放。尝试获取锁时客户端对指定的Key执行acquire操作并将该Key与自己的Session绑定。同一时刻只有一个Session能成功绑定获取该Key即获得锁。检查与等待如果acquire失败Key已被其他Session绑定客户端可以轮询查询该Key的状态或使用阻塞查询等待锁释放。2. 核心特性与优势服务发现集成Consul本身是服务发现与配置中心锁机制与其生态无缝集成。自动释放基于Session客户端故障时锁自动释放避免死锁。一致性Consul使用Raft协议保证强一致性默认也可配置为弱一致性模式以提高性能。HTTP/gRPC API通过简单的HTTP API即可操作易于理解和集成。3. 常见面试问题一致性模式Consul的读操作可以配置为default强一致、consistent强一致或stale弱一致读任意节点。分布式锁通常使用强一致模式。Session与TTLSession依赖健康检查Check或TTL来维持。如果客户端无法更新TTL或健康检查失败Session会失效锁释放。需要客户端保持活跃。性能相比ZooKeeperConsul的HTTP API可能更易于使用但强一致性下的写性能仍需Raft多数派确认。三、ZooKeeper与Consul对比总结对比维度ZooKeeperConsul数据模型树形节点ZNodeKey/Value存储锁实现核心临时顺序节点 Watch监听KV Session机制一致性强一致性ZAB协议强一致性Raft协议可配置锁释放机制会话结束临时节点自动删除Session失效Key自动释放公平性原生支持顺序节点依赖实现通常FIFO客户端复杂度较高需处理Watch、重试较低HTTP API简单生态定位分布式协调服务服务发现、配置、健康检查适用场景对强一致性和可靠性要求极高的核心系统微服务架构中已使用Consul做服务发现需要轻量级锁的场景四、高频面试题速答ZooKeeper分布式锁如何避免羊群效应答让每个客户端只监听Watch它前一个顺序节点的删除事件而不是所有客户端都监听锁节点。这样锁释放时只会通知下一个等待的客户端。ZooKeeper锁的临时节点有什么作用答临时节点与客户端会话绑定会话结束客户端宕机或网络断开时节点自动删除从而自动释放锁防止死锁。Consul的Session是什么在锁中起什么作用答Session是Consul中一个代表客户端会话的抽象与健康检查或TTL绑定。锁KV与Session关联Session失效则锁自动释放保证了锁的安全性。两者在性能上如何考量答ZooKeeper写需集群多数确认延迟较高但强一致。Consul的HTTP API更友好但强一致模式下同样需要Raft多数确认。若对性能极度敏感且可接受弱一致可考虑Redis若要求强一致两者性能相近选型更取决于技术栈和生态。如何实现锁的可重入答在锁节点ZooKeeper或Key值Consul中存储客户端标识和重入计数。同一客户端再次获取锁时检查标识并增加计数释放时减少计数计数为0时才真正释放资源。