Zookeeper 是什么？它有哪些核心特性和应用场景？\n\nZookeeper 是 Apache 维护的开源分布式协调服务，通过层次化命名空间和 Watcher 机制，为分布式应用提供配置管理、服务发现、分布式锁等协调能力。它本质上是一个高可用的分布式小文件存储系统，读多写少，适合做"共识"而非"存储"。\n\n## 核心特性\n\n一致性保证：所有客户端看到的数据视图一致，事务请求按顺序严格执行，要么全部成功要么全部失败。\n\n高可用：集群部署（通常3/5/7节点），过半节点存活即可服务。Leader 处理写请求并通过 ZAB 协议同步到 Follower，Follower 处理读请求，Observer 扩展读性能但不参与选举。\n\nWatcher 机制：客户端可对节点注册监听，数据变更时服务端主动推送通知。这是实现配置动态更新、服务上下线感知的基础。注意 Watcher 是一次性的，触发后需重新注册。\n\n## 数据模型\n\nZookeeper 采用树形结构，每个节点称为 ZNode。四类节点：\n\n- 持久节点：创建后永久存在，除非显式删除\n- 临时节点：绑定会话，断连自动删除——这是服务注册和分布式锁的实现基础\n- 持久顺序节点：自动追加递增序号，用于分布式队列\n- 临时顺序节点：临时+顺序，分布式锁的公平实现方式\n\n每个 ZNode 维护 dataVersion（数据版本）、cversion（子节点版本）、aversion（ACL版本），实现乐观锁。\n\n## 典型应用场景\n\n- 配置中心：节点存配置，Watcher 监听变更，实现动态推送\n- 服务注册与发现：服务启动时写临时节点，宕机自动摘除\n- 分布式锁：临时顺序节点实现公平锁，避免羊群效应\n- Leader 选举：利用临时顺序节点，序号最小的节点成为 Leader\n\n## 追问\n\nZAB 协议和 Paxos 的区别？ ZAB 专为 Zookeeper 设计，支持崩溃恢复和消息广播两种模式，强调主备切换时的数据一致性；Paxos 是通用一致性算法，ZAB 可视为其简化变体，在 Leader 选举效率上更优。\n\n临时节点在什么情况下不会立即删除？ 会话超时而非连接断开时触发删除。网络抖动期间客户端可能在其他 Server 上重建会话，此时临时节点迁移而非删除。
