《从 PAXOS 到 ZOOKEEPER》：一致性从证明到工程

从一致性问题、Paxos 和 Zab 进入 ZooKeeper 的工程实现与使用边界。

笔记状态：结构化初读｜作者：倪超

版本与阅读范围

本地文件共 433 个扫描页，围绕分布式一致性、Paxos、ZooKeeper 数据模型、会话、Zab、服务端/客户端实现与典型应用展开。报告用 Paxos 和 ZooKeeper 原始资料校正概念边界。

一句话结论

分布式协调的难点不只是“节点会坏”，而是在消息延迟、重试、并发和部分失败下，明确哪些安全性质永远不能破坏、哪些活性性质只能在条件满足时保证。

核心论点一：先区分安全性与活性

一致性算法首先要求不会决定两个冲突值，这是安全性；系统最终能继续决定值属于活性。异步网络无法仅凭超时判断节点死亡，因此工程系统常用超时和领导者提高进展，却不能把怀疑等同于事实。

这是形式化论证的入口：先写不变量，再说明法定人数交集为何保护不变量。Lamport 在《Paxos Made Simple》中指出算法本身可以由 proposer、acceptor 和多数派规则简洁描述。原始论文页面

核心论点二：多数派交集把一次决定连接到下一次决定

任意两个多数派至少共享一个成员。后续提议必须了解更早轮次中可能被选择的值，从而不能覆盖已决定结果。编号轮次解决并发提议者争夺，但领导者、日志复制和成员变更会增加工程复杂度。

书从 Paxos 过渡到 Zab，强调生产系统不仅需要单值共识，还需要连续事务顺序、崩溃恢复、快照和客户端语义。不能把“实现了多数投票”直接等同于正确共识。

核心论点三：ZooKeeper 提供协调原语，不是透明一致性魔法

临时节点、顺序节点、watch 和版本号可构造选主、锁、配置与成员发现。正确性仍取决于会话过期、一次性 watch、羊群效应和 fencing；客户端断开时无法总能知道操作是否成功。

ZooKeeper 原始论文把目标描述为高性能协调服务，并通过有序请求和以读为主的工作负载取得吞吐。USENIX ZooKeeper 论文

业界对照与不同观点

• ZooKeeper 官方配方给出锁、屏障、队列和选主，同时明确错误处理和可恢复锁的复杂性。配方是起点，不是自动正确证明。Apache ZooKeeper Recipes
• Raft 以可理解性为设计目标，把选主、日志复制和安全性分解描述；许多团队觉得它比 Paxos 更容易教学和实现，但“更容易理解”不代表可以跳过不变量。Raft 官方论文站
• 分布式锁若用于保护外部资源，还需要 fencing token；仅持有一个可能过期的锁不足以阻止旧客户端写入。

时效性判断

一致性基本原理长期有效；ZooKeeper 版本、源码结构和运维建议会变化。当前工程还应比较 etcd/Raft、云协调服务和数据库自身事务能力，不默认引入独立协调系统。

读后行动

1. 为一个选主协议写出安全不变量和活性前提。
2. 模拟请求成功但响应丢失，判断客户端能否安全重试。
3. 设计锁时补上会话过期、fencing 和外部副作用分析。

最终评价

本书适合作为中文工程入口，但不能替代原始论文和故障实验。读懂算法的标准不是复述角色，而是能说明不变量、失败窗口和恢复路径。