第九章：一致性与共识

第九章一致性与共识这一章是全书理论难度最高的一章也是分布式系统的核心命题。第八章揭示了分布式系统的不确定性——网络不可靠、时钟不可靠、进程会暂停、没有全局真相。第九章则要回答在这样一片混乱之上我们究竟能建立什么样的保证Kleppmann 的论点是一致性不是单一概念而是一个从强到弱的谱系共识是分布式系统中最强大的原语但代价高昂且不能解决所有问题。本章结构先讲线性一致性最强的一致性模型再讲顺序与因果性然后讲共识问题及其算法最后讲分布式事务与协调服务。一、一致性模型的谱系1. 为什么需要一致性模型在分布式系统中一致性这个词被滥用得很厉害。它可能指副本一致性多个副本之间的数据是否相同事务隔离性并发事务之间的可见性线性一致性单一对象的强一致性保证共识多个节点对某个值达成一致本章聚焦的是分布式系统层面的一致性即多个副本、多个节点之间的保证。2. 一致性模型的强度谱系线性一致性Linearizability—— 最强 ↑ 顺序一致性Sequential Consistency ↑ 因果一致性Causal Consistency ↑ 写后读 / 单调读 / 一致前缀读 ↑ 最终一致性Eventual Consistency—— 最弱越强的一致性越容易编程代价越高延迟、可用性越难实现二、线性一致性Linearizability1. 定义线性一致性也叫原子一致性Atomic Consistency、强一致性Strong Consistency、外部一致性External Consistency。核心思想系统看起来像是只有一个副本所有操作都是原子的且按某个全局顺序执行这个顺序与真实时间一致。更精确地说每个操作在调用和返回之间某个时间点生效如果操作 A 在操作 B 开始之前完成那么 A 必须在 B 之前生效所有节点看到相同的操作顺序2. 线性一致性的直观理解例子用户 A 写入 x1写入成功后用户 B 立即读取 x必须读到 1不能出现 B 读到旧值的情况线性一致性 vs 可串行化可串行化事务的隔离级别保证并发事务等同于串行执行线性一致性单一对象的读写保证保证操作按真实时间排序两者可以结合严格可串行化Strict Serializability3. 线性一致性的代价1性能需要协调延迟高通常需要共识算法Paxos、Raft跨数据中心线性一致性延迟极高2可用性CAP 定理网络分区时线性一致性必须牺牲可用性这是不可避免的权衡3实现复杂需要处理网络分区、时钟、进程暂停需要共识算法4. 线性一致性的应用场景分布式锁必须线性一致唯一性约束如用户名注册领导者选举必须线性一致金融交易强一致性要求Kleppmann 的提醒线性一致性很强但不是所有场景都需要。很多场景可以用更弱的一致性换取更高的性能和可用性。三、顺序一致性与因果一致性1. 顺序一致性Sequential Consistency定义所有节点看到相同的操作顺序但这个顺序不必与真实时间一致。与线性一致性的区别线性一致性顺序必须与真实时间一致顺序一致性只要所有节点看到相同顺序即可例子线性一致性A 写 x1B 立即读必须读到 1顺序一致性A 写 x1B 读可能读到旧值但所有节点看到的顺序一致2. 因果一致性Causal Consistency定义只保证因果相关的操作按顺序被看到无因果关系的操作可以任意顺序。因果关系的例子A 发帖B 回复。B 的回复因果依赖于 A 的帖子。所有节点必须先看到 A 的帖子再看到 B 的回复。因果一致性的优势比线性一致性弱性能更好比最终一致性强避免因果错乱是很多系统的实用选择实现版本向量Version Vectors因果依赖追踪Kleppmann 的观点因果一致性是最弱的有用一致性。它避免了因果错乱又不牺牲太多性能。3. 因果顺序与全序全序Total Order所有事件可以比较先后线性一致性需要全序偏序Partial Order只有部分事件可以比较因果一致性只需要偏序关键洞察分布式系统中建立全序需要共识代价高。很多时候偏序因果顺序就足够了。四、共识问题1. 什么是共识共识Consensus多个节点对某个值达成一致。形式化所有节点提议一个值最终所有节点决定同一个值这个值必须是某个节点提议的共识的性质一致性Agreement所有节点决定相同的值有效性Validity决定的值必须是某个节点提议的终止性Termination所有节点最终都会决定完整性Integrity每个节点只决定一次2. 共识的困难FLP 不可能定理在异步系统中即使只有一个节点可能崩溃也不存在一个确定性的共识算法能保证终止。意味着纯异步系统无法保证共识实际系统需要部分同步假设超时、时钟或者接受概率性终止3. 共识算法1PaxosLamport 提出最经典的共识算法角色Proposer、Acceptor、Learner两阶段Prepare、Accept优点理论完备缺点难理解、难实现2Raft为可理解性设计角色Leader、Follower、Candidate强领导者所有写经过 Leader阶段选举、日志复制代表etcd、Consul、TiKV3ZABZooKeeper Atomic BroadcastZooKeeper 使用类似 Raft但有细微差别用于分布式协调4拜占庭容错BFT处理恶意节点PBFT、PoW、PoS区块链场景4. 共识的应用领导者选举选出唯一主节点分布式锁保证互斥原子提交分布式事务配置管理ZooKeeper、etcd成员管理集群成员变更五、分布式事务与两阶段提交1. 分布式事务的挑战事务跨多个节点需要原子性要么全部提交要么全部回滚网络分区、节点故障使问题复杂2. 两阶段提交2PC, Two-Phase Commit阶段一准备Prepare协调者问所有参与者“能提交吗”参与者回复可以或不行阶段二提交/回滚Commit/Abort如果所有参与者都说可以协调者决定提交否则回滚协调者通知所有参与者问题阻塞参与者准备后必须等待协调者决定协调者故障参与者可能永远等待性能需要多次网络往返Kleppmann 的批评2PC 是一个阻塞式原子提交协议。它在协调者故障时会阻塞这是它最大的问题。3. 三阶段提交3PC增加一个阶段减少阻塞但仍不能完全避免实际使用较少4. 共识与 2PC 的关系2PC 不是共识算法但它可以用共识算法实现如 Raft 2PC现代分布式数据库常用共识 复制状态机替代 2PC5. 分布式事务的替代方案Saga长事务拆成多个本地事务用补偿操作回滚TCCTry-Confirm-Cancel最终一致性接受暂时不一致六、协调服务与成员管理1. ZooKeeper 与 etcd功能分布式配置管理命名服务分布式锁领导者选举成员管理核心基于共识算法ZAB、Raft提供线性一致性保证小数据量高可用2. 成员管理问题集群中哪些节点是活的节点加入/离开如何处理网络分区时如何判断解决用共识算法维护成员列表心跳 超时但超时无法区分慢和死3. 协调服务的限制不适合存储大量数据不适合高吞吐是系统的关键路径故障影响大Kleppmann 的提醒协调服务是分布式系统的大脑但它本身也是分布式系统也需要容错。不要把它当作万能药。七、本章的核心思想总结主题核心观点线性一致性最强一致性代价高需要共识顺序一致性所有节点看到相同顺序不必与真实时间一致因果一致性最弱的有用一致性避免因果错乱共识分布式系统最强原语FLP 定理限制其终止性共识算法Paxos、Raft、ZAB、BFT2PC阻塞式原子提交协调者故障时阻塞协调服务ZooKeeper、etcd基于共识是系统的关键路径三个贯穿全书的判断一致性是谱系不是二元从线性一致到最终一致选哪个取决于业务需求。共识是分布式系统的核心原语领导者选举、分布式锁、原子提交都依赖它。共识不是免费的它需要多数派、网络往返、持久化代价高昂。八、这一章在全书中地位第九章是分布式系统理论的顶峰第五章数据复制复制模型需要一致性保证第六章数据分区分区映射的协调需要共识第七章事务分布式事务需要原子提交第八章分布式系统挑战网络、时钟、进程暂停是共识要解决的问题第十章批处理、第十一章流处理大规模数据处理依赖共识做协调一句话概括本章一致性是一个从线性一致到最终一致的谱系线性一致性最强但代价最高。共识是分布式系统中最强大的原语用于领导者选举、分布式锁和原子提交但受 FLP 定理限制需要部分同步假设。2PC 是阻塞式原子提交协议协调者故障时会阻塞。协调服务ZooKeeper、etcd基于共识是分布式系统的关键路径。理解这些才能设计出真正可靠的分布式系统。