分布式一致性算法详解：从 2PC、3PC 到 Paxos、Raft、ZAB

在单机系统里“一致性”通常意味着一次写入要么成功、要么失败读到的数据应该符合预期。但在分布式系统中数据被拆分到多台机器上节点可能宕机网络可能延迟、丢包、分区消息可能乱序到达。此时“让多个节点对同一件事达成一致”就变成了一个核心难题。分布式一致性算法的目标就是在不可靠的网络和节点环境中让多个副本尽可能可靠地就某个值、某个日志顺序、某个事务结果达成一致。一、为什么需要分布式一致性典型场景包括分布式数据库主从复制分布式事务提交配置中心的配置变更注册中心的服务上下线分布式锁元数据管理多副本日志复制分布式文件系统 Master 高可用假设有三个节点 A、B、C它们都保存用户余额A: balance 100 B: balance 100 C: balance 100现在用户转出 30 元A 已经更新为 70但 B、C 还没来得及更新。如果此时系统对外提供读服务就可能读到不同结果。这就是分布式系统里的核心问题多个副本如何保持一致。二、一致性的不同层次1. 强一致性强一致性要求一次写入成功后后续所有读都能读到最新值。例如写入 x 1 成功 之后任意节点读取 x都必须返回 1强一致性的用户体验最好但实现成本最高通常会牺牲可用性或性能。2. 最终一致性最终一致性允许短时间内不同节点看到不同数据但只要没有新的写入系统最终会收敛到相同状态。例如A 节点已经更新 B、C 节点稍后同步 最终 A、B、C 数据一致DNS、缓存系统、很多互联网业务系统都大量使用最终一致性。3. 线性一致性线性一致性是强一致性的一种严格形式。它要求所有操作看起来像是按照某个全局顺序依次执行并且这个顺序符合真实时间。如果操作 A 在操作 B 开始前已经完成那么所有节点都必须认为 A 发生在 B 之前。Raft、Paxos 这类共识算法通常追求的就是线性一致的日志复制。三、CAP 理论CAP 理论指出在分布式系统中以下三者不能同时完全满足Consistency一致性Availability可用性Partition Tolerance分区容错性网络分区在分布式系统中无法彻底避免所以实际系统通常必须在 CP 和 AP 之间取舍。CP 系统CP 系统优先保证一致性和分区容错性。当网络分区发生时为了避免数据冲突一部分节点可能拒绝服务。代表系统ZooKeeperetcdConsul 的一致性存储部分HBase 的强一致元数据管理AP 系统AP 系统优先保证可用性和分区容错性。当网络分区发生时各分区仍然可以处理请求但后续需要通过冲突合并、版本比较等方式实现最终一致。代表系统CassandraDynamoDB 的部分设计思想RiakCouchDB四、2PC两阶段提交2PC全称 Two-Phase Commit是经典的分布式事务提交协议。它主要解决的问题是多个参与者要么全部提交要么全部回滚。阶段一Prepare协调者询问所有参与者是否可以提交事务。Coordinator - Participant A: Can commit? Coordinator - Participant B: Can commit? Coordinator - Participant C: Can commit?参与者执行本地预提交操作锁定资源然后回复YES / NO阶段二Commit / Rollback如果所有参与者都返回 YES协调者发送 COMMIT。只要有一个参与者返回 NO协调者发送 ROLLBACK。所有人 YES - COMMIT 任意人 NO - ROLLBACK2PC 的优点模型简单容易理解能保证事务原子性适合传统数据库 XA 事务场景2PC 的缺点2PC 最大的问题是阻塞。如果协调者在第二阶段宕机参与者可能已经进入 prepared 状态并且不知道最终应该提交还是回滚。此时参与者为了保证一致性只能继续阻塞等待协调者恢复。Participant A: 已 prepared但不知道最终结果 Participant B: 已 prepared但不知道最终结果 Coordinator: 宕机这会导致资源长时间被锁住影响系统可用性。五、3PC三阶段提交3PC全称 Three-Phase Commit是对 2PC 的改进。它将 2PC 的提交过程拆成三个阶段CanCommitPreCommitDoCommit3PC 的核心思路3PC 在提交前增加了一个 PreCommit 阶段试图减少 2PC 中参与者长时间阻塞的问题。流程大致如下CanCommit: 询问是否可以提交 PreCommit: 通知即将提交 DoCommit: 正式提交3PC 的优点相比 2PC阻塞风险降低引入超时机制后参与者可以在部分场景下自行决策3PC 的缺点3PC 依然不能完美解决网络分区问题。如果发生网络分区不同节点可能基于超时做出不同决策导致一致性被破坏。因此3PC 在真实工程系统中使用并不多。六、Paxos经典共识算法Paxos 是分布式一致性领域最著名、也最难理解的算法之一。它解决的问题是在多个可能失败的节点之间对某个值达成一致。Paxos 中有三个角色Proposer提议者提出某个值Acceptor接受者对提案投票Learner学习者学习最终被选定的值一个节点可以同时扮演多个角色。Paxos 的基本约束Paxos 希望满足只能有一个值最终被选定被选定的值必须是某个 Proposer 提出的值一旦某个值被选定所有 Learner 最终都能学习到这个值少数节点故障不影响整体决策只要多数派可用多数派机制Paxos 依赖多数派 Quorum。如果有 5 个节点那么多数派至少是 3 个。任何两个多数派一定有交集。多数派 1: A B C 多数派 2: C D E 交集: C这个交集非常关键。它保证后续提案可以知道之前可能已经被接受的值从而避免多个值同时被选定。Paxos 两个阶段第一阶段Prepare / PromiseProposer 生成一个全局递增的提案编号 n向多数 Acceptor 发送 Prepare 请求。Prepare(n)Acceptor 收到后如果 n 大于它见过的所有提案编号就承诺不再接受编号小于 n 的提案返回自己曾经接受过的最大编号提案和值这叫 Promise。第二阶段Accept / AcceptedProposer 收到多数派 Promise 后根据规则选择值如果没有 Acceptor 返回已接受的值可以使用自己的值如果有 Acceptor 返回已接受的值必须选择编号最大的那个已接受值然后 Proposer 向多数 Acceptor 发送 Accept 请求。Accept(n, value)Acceptor 如果没有承诺过更大的编号就接受该提案。当某个值被多数 Acceptor 接受时这个值就被选定。Paxos 的优点理论严谨能容忍少数节点故障基于多数派保证一致性是很多共识算法的理论基础Paxos 的缺点难理解难实现工程落地复杂原始 Paxos 只决定一个值实际系统需要 Multi-Paxos 来复制日志七、Multi-Paxos单次 Paxos 只能对一个值达成一致。但真实系统通常需要对一系列操作达成一致例如log[1] set x 1 log[2] set y 2 log[3] delete zMulti-Paxos 就是把 Paxos 扩展到多条日志。它通常会选出一个稳定 Leader由 Leader 负责连续发起提案。这样可以减少 Prepare 阶段的开销提高性能。Multi-Paxos 的核心优化普通 Paxos 每次提交都需要两轮通信Prepare - Promise Accept - AcceptedMulti-Paxos 在 Leader 稳定的情况下可以复用 Leader 身份后续日志只需要 Accept 阶段。Accept - Accepted这让它更适合工程系统。八、Raft更容易理解的共识算法Raft 的目标是提供一个比 Paxos 更容易理解、也更容易实现的共识算法。很多现代分布式系统使用 Raft例如etcdConsulTiKVNacos 部分一致性实现CockroachDB 的部分复制机制Raft 把共识问题拆成三个子问题Leader 选举日志复制安全性保证九、Raft 的角色Raft 中每个节点有三种状态Leader领导者处理客户端请求并复制日志Follower跟随者被动接收 Leader 消息Candidate候选者发起选举正常情况下一个 Raft 集群只有一个 Leader。Client - Leader - Followers十、Raft Leader 选举Raft 使用任期 term 来区分不同选举周期。每个节点启动时都是 Follower。如果 Follower 在 election timeout 时间内没有收到 Leader 的心跳就会变成 Candidate并发起选举。选举流程当前节点 term 1将自己变成 Candidate给自己投票向其他节点发送 RequestVote获得多数票后成为 Leader为什么需要随机超时如果所有节点同时超时就会同时发起选举导致票数分散。Raft 使用随机 election timeout降低选票冲突概率。Node A timeout: 150ms Node B timeout: 230ms Node C timeout: 310ms通常最早超时的节点会先发起选举并更容易成为 Leader。十一、Raft 日志复制客户端写请求会先发送给 Leader。Leader 将操作追加到自己的日志中然后并行发送给 Followers。Client - Leader: set x 1 Leader append log Leader - Followers: AppendEntries Followers append log Followers - Leader: success Leader receives majority success Leader commits log Leader applies to state machine只要日志被多数节点复制成功Leader 就可以提交该日志。已提交日志一条日志被多数节点保存后就可以认为是 committed。提交后Leader 会把这条日志应用到状态机并通过后续心跳通知 Followers 也提交。log[8] copied to A, B, C 5 节点集群中已有 3 个节点保存 log[8] committed十二、Raft 的安全性Raft 通过几个规则保证安全。1. Leader 只追加日志Leader 不会覆盖或删除自己的日志只会追加新日志。2. 日志匹配原则如果两个日志条目拥有相同的 index 和 term那么它们之前的所有日志也完全相同。log[5].term 3 如果两个节点的 log[5] 都是 term 3 那么 log[1..5] 都应该一致3. Leader 完整性如果某条日志已经在某个任期被提交那么之后所有 Leader 都必须包含这条日志。这是 Raft 能够保证已提交数据不丢失的关键。十三、ZABZooKeeper 的一致性协议ZAB全称 ZooKeeper Atomic Broadcast是 ZooKeeper 使用的一致性协议。ZAB 和 Raft 很相似也依赖 Leader 和多数派机制。ZooKeeper 的数据更新必须经过 Leader然后广播给 Followers。ZAB 的核心目标ZAB 主要保证原子广播全局有序崩溃恢复Leader 切换后数据不丢失ZAB 的基本流程Client 向 ZooKeeper 发起写请求请求转发给 LeaderLeader 生成事务 ProposalLeader 广播 Proposal 给 Followers多数 Followers 返回 ACKLeader 发送 COMMIT各节点应用事务Client - Leader Leader - Followers: Proposal Followers - Leader: ACK Leader - Followers: COMMIT十四、Raft 与 ZAB 的区别Raft 和 ZAB 都使用 Leader 和多数派但关注点略有不同。对比项RaftZAB典型系统etcd、ConsulZooKeeper核心模型复制日志原子广播Leader 选举Raft 自身定义ZooKeeper 选举机制写入路径Leader 复制日志Leader 广播事务工程目标易理解、易实现服务 ZooKeeper 数据模型一致性基础多数派多数派十五、Gossip最终一致性的传播协议Gossip 不是强一致性共识算法而是一种最终一致性传播协议。它的思想类似流言传播。一个节点知道某个消息后会随机告诉其他节点。被通知的节点再继续传播。A - B, C B - D C - E D - F经过多轮传播后整个集群最终都会知道这个消息。Gossip 的优点去中心化可扩展性强容错性好适合大规模集群状态传播Gossip 的缺点不保证强一致收敛有延迟短时间内不同节点状态可能不同典型应用Cassandra 节点状态传播Consul 成员发现Dynamo 风格系统分布式缓存节点状态同步十六、常见算法对比算法类型一致性是否依赖 Leader是否阻塞典型场景2PC分布式事务协议强一致事务结果协调者会阻塞XA 事务3PC分布式事务协议尽量强一致协调者降低阻塞理论方案较多Paxos共识算法强一致不强制固定 Leader不依赖单点理论共识Multi-Paxos日志共识强一致通常有 Leader多数派可用即可分布式存储Raft日志共识强一致是多数派可用即可etcd、ConsulZAB原子广播强一致是多数派可用即可ZooKeeperGossip传播协议最终一致否不阻塞状态传播十七、如何选择一致性算法1. 如果你要做分布式事务可以考虑本地消息表SagaTCC2PC / XA但在高并发互联网系统中强 XA 事务通常不是首选因为它会带来资源锁定、性能下降和可用性问题。更常见的做法是业务补偿加最终一致性。2. 如果你要做配置中心或注册中心可以考虑RaftZABMulti-Paxos这类系统通常要求元数据强一致因为配置错误或服务发现错误会影响整个系统。3. 如果你要做大规模状态传播可以考虑 Gossip。例如节点上下线、心跳状态、缓存拓扑变化等场景不一定需要所有节点立即强一致。4. 如果你要做分布式锁应该优先选择已经成熟的 CP 系统例如ZooKeeperetcd分布式锁对一致性要求很高不建议基于普通缓存系统随意实现。十八、工程实践中的取舍真实系统很少只追求单一指标。一致性越强通常意味着写入延迟更高可用性更容易受网络影响系统实现更复杂运维成本更高一致性越弱通常意味着性能更好可用性更高业务需要处理冲突需要补偿、重试、幂等和对账机制所以工程上真正重要的问题不是“哪个算法最好”而是这个业务到底需要多强的一致性 数据短暂不一致会造成什么后果 是否可以通过补偿机制修复 用户是否能感知 资金、库存、权限、配置等关键数据是否允许最终一致十九、一个简单的选择建议业务场景推荐一致性策略金融转账强一致或可靠最终一致必须有对账库存扣减强约束库存可用 CP普通库存可最终一致用户资料更新最终一致通常可接受配置中心强一致注册中心CP 或 AP 取决于业务容忍度分布式锁强一致日志采集最终一致缓存同步最终一致订单状态流转本地事务 消息最终一致 幂等二十、总结分布式一致性算法本质上是在不可靠环境中协调多个节点的决策。2PC 和 3PC 主要面向分布式事务提交强调多个参与者对事务结果达成一致。Paxos、Multi-Paxos、Raft 和 ZAB 属于共识或日志复制协议强调多个节点对操作顺序和状态变更达成一致。Gossip 则不追求强一致而是通过传播机制实现最终一致适合大规模状态同步。在工程实践中一致性不是越强越好。强一致能减少业务复杂度但会牺牲性能和可用性最终一致性能提升系统吞吐和容错能力但要求业务具备幂等、重试、补偿和对账能力。设计分布式系统时最重要的是先判断业务的一致性边界再选择合适的算法和架构而不是盲目追求某个“最强”的一致性方案。