5.5 分布式一致性ZooKeeper
内容提要
文章介绍分布式一致性与ZooKeeper：先说明脑裂问题，ZooKeeper作为管理中心仲裁故障服务器；接着讲Paxos的Proposer、Acceptor、Learner三角色及Prepare、Accept、Learn三阶段，强调Proposal ID唯一递增；再述ZooKeeper架构与Zab协议，leader向follower发起Propose并收集ack；还列举配置管理、选主、集群管理等API用法，最后指出读吞吐强于写。
延伸解读
脑裂与 ZooKeeper 的仲裁角色
文章开篇指出分布式系统脑裂源于不同服务器获得冲突数据或指令，导致集群混乱和数据损坏。ZooKeeper 在此场景中作为管理中心，对故障服务器进行仲裁，并保证多台服务器数据存储的一致性。这提示读者：ZooKeeper 的价值不仅在于存储配置，更在于为集群提供统一的协调点，避免节点各自为政。
Paxos 三阶段与 Proposal ID 的约束
文章将 Paxos 拆解为 Proposer、Acceptor、Learner 三角色，以及 Prepare、Accept、Learn 三阶段。关键细节是 Proposal ID 必须全局唯一且递增，Acceptor 会拒绝 ID 不大于当前请求的 Prepare，以及 ID 小于当前请求的 Propose。这意味着提案顺序是算法安全性的基础，读者在理解或实现类似协议时，应重点关注 ID 的生成与比较规则。
Zab 协议中 leader 与 follower 的交互
在 ZooKeeper 架构部分，文章说明客户端请求会先到达 leader，leader 再向 follower 发起 Propose，并收集 ack 以确认状态正常。这与 Paxos 的多数派接受思路相呼应，但更强调 leader 在请求处理中的中心作用。读者可借此理解 ZooKeeper 写操作的基本路径：请求集中到 leader，再通过 follower 的确认形成一致性。
API 用法背后的协调模式
文章列举了配置管理、选主和集群管理的 API 用法。配置管理通过 setData 与 getData 配合 watch 实现变更通知；选主利用临时节点和 getData 的 watch 机制，让候选者竞争创建 leader 节点；集群管理则通过临时节点和周期性状态更新来跟踪节点存活与负载。这些例子展示了 ZooKeeper 树状结构如何承载常见的分布式协调模式，而不仅是简单的数据存储。
Q&A
分布式系统中的脑裂是什么？ZooKeeper如何解决脑裂问题？
脑裂指分布式系统中不同服务器获得冲突的数据或指令，导致集群混乱和数据损坏。ZooKeeper作为管理中心，对故障服务器进行仲裁，保证多台服务器数据存储的一致性。
Paxos算法中的三个角色分别是什么？各自负责什么？
Paxos有三个角色：Proposer提交提案；Acceptor接受提案；当超过半数的Acceptor接受提案后，Learner接受该提案。
Paxos算法的三个阶段具体流程是怎样的？
第一阶段Prepare：Proposer向Acceptors发Prepare请求，Acceptors进行Promise承诺；第二阶段Accept：Proposer收到多数Promise后发Propose请求，Acceptors进行Accept处理；第三阶段Learn：Proposer收到多数Accept后决议形成，将决议发送给所有Learners。
Paxos中Proposal ID的唯一性和递增性如何保证？Acceptors如何处理请求？
Proposer生成全局唯一且递增的Proposal ID（可用时间戳加ServerID），Prepare请求只携带Proposal ID。Acceptors收到请求后，不再接受Proposal ID小于等于当前请求的Prepare请求，也不再接受Proposal ID小于当前请求的Propose请求。
ZooKeeper的Zab协议中，leader和follower如何交互？
客户端请求会走到leader，leader向follower发起Propose，如果返回ack，说明状态正常。
ZooKeeper在配置管理中的API用法是什么？
管理员使用setData("/config/param1", "value", -1)设置配置；消费者使用getData("/config/param1", true)获取配置并监听变化。
ZooKeeper如何实现选master？
通过getdata("/servers/leader", true)尝试获取leader信息，若成功则跟随数据中描述的leader并退出；否则通过create("/servers/leader", hostname, EPHEMERAL)创建临时节点，若成功则成为leader并退出，否则重试。
ZooKeeper的读写性能有什么特点？
ZooKeeper读的吞吐能力比写更强；3台服务器的初期吞吐量比13台服务器更低。
