Paxos 共识算法：从多数派原理到高可用架构落地-北京尧图网络

我在做分布式系统可靠性设计那段时间最常被问到的一句话是三节点集群一台机器突然断电业务还能正常写吗很多人第一反应是能毕竟还有两台。那如果再把问题收紧一点两台机器的集群再挂一台呢这时候答案就变得很微妙了——系统可能还活着但任何数据变更都不能安全落盘了。这背后的机制就是 Paxos 共识算法在起作用。这篇博文我把自己的一线理解梳理一遍从核心原理讲到工程落地包括为什么会需要两阶段提交、多数派为什么能扛故障、Multi-Paxos 和 Raft 的关系以及在配置中心、分布式锁、元数据存储这些高可用场景里Paxos 到底是怎么把“一台挂了业务还能继续”这件事变成现实的。适合刚开始啃分布式协议的人也适合已经在各种中间件上踩过坑、想真正搞懂底层原理的人。1. 高可用性的本质与 Paxos 要回答的问题1.1 副本、复制状态机与容错模型高可用性不是说一台机器有多稳定而是指整个系统在部分组件失效时依然能对外提供正确的服务。这个目标往底层走靠的是“多副本”。把同一份数据复制到多个节点上一台挂了还有另一台顶上听起来很朴素但复制本身就埋着坑如果两台机器各自接收了不同的写入数据就分叉了用户读到的结果可能完全不一样。所以多副本的关键不是“多存几份”而是“所有副本最终对同一组操作达成一致的顺序”。这个模型在分布式系统里有个专门说法叫复制状态机。每个节点上跑同一个确定性状态机只要所有节点按相同的顺序执行相同的请求最终状态就是一致的。比如一个 KV 存储节点 A 先处理set x 1再处理set x 2节点 B 也按这个顺序处理那么两个节点里 x 的值都会是 2。问题就变成了怎么让所有节点对“先执行哪个请求、后执行哪个请求”达成共识这恰恰是分布式系统最难啃的骨头之一。难在哪因为故障模型太现实了。节点可能直接宕机网络可能断连消息可能延迟、丢失或者乱序到达。更头疼的是你没法准确区分“对方挂了”和“消息还在路上”这种超时不确定性会让所有天真的解决方案翻车。1.2 为什么说一致性协议是高可用的地基面对上述问题最简单的方案是主备模式固定选一个主节点所有写入都走它其他节点同步数据。主节点挂了就由人工或者某个守护进程切换新的主。这套方案实现简单但隐患在于“旧主到底是活着还是死了”。假设主 A 网络抖动监控系统认为它挂了便切换主到 B。可 A 其实只是被临时隔离它自己并不知道自己已经被切换还在继续处理写入。此时系统里就有两个主在同时写入用户一会读到 A 的数据一会读到 B 的数据这就是脑裂。脑裂不是小概率事件它恰恰是分布式系统里最常见的事故原因。Paxos 这类共识算法解决的正是这个更深层的问题在一个节点可能宕机、网络可能分区的环境里如何让一群节点就“某个值”达成唯一的一致并且保证这个一致结果在部分节点故障时依然有效。它的思路不是找一个“永远不会死的中心节点”而是让决策权分散到所有参与者手里通过“多数派”来形成决策。一台挂了只要剩下的节点还能组成多数派系统就能继续工作大多数节点都挂了那系统再等等它们活过来再恢复。这不是靠某个节点可靠而是靠整个集体冗余来撑起高可用。2. Paxos 算法核心原理拆解2.1 三种角色与提案编号Paxos 把一个决策过程抽象成三类角色每个角色有明确的职责Proposer提议者负责发起提案想把某个值提交给整个集群。Acceptor接受者负责参与投票、存储已接受的值。它是最核心的角色因为决策的安全全靠 Acceptor 的“承诺”来维持。Learner学习者不参与投票只学习最终被多数派接受的值然后执行对应的操作。实际系统里一个节点通常可以同时扮演多个角色比如既是 Proposer 也是 Acceptor 和 Learner。角色分离主要是为了理清逻辑不是硬性的进程划分。提案由一个编号和一个绑定值组成。编号必须是全序递增、且全局唯一的通常用一个单调递增的整数或者“轮次号节点 ID”的组合来实现。为什么不能用时间戳代替因为不同节点的物理时钟可能不同步会出现两个人提出相同编号或者后提出的编号反而更小的情况这会让协议的安全保证失效。编号的本质就是一个逻辑时钟它只关心先后次序不关心墙上时间。每个 Acceptor 需要记住两个信息它曾经回应过的最大的提案编号以及它已经接受的最大的编号对应的提案。这两条记忆是整个协议安全性的根基后面会反复用到。2.2 多数派 Quorum 的数学保证Paxos 的整个设计都建立在“多数派”这个概念上所谓一个提案被通过不是看全体成员是否同意而是看是否有一个超过半数的 Acceptor 接受了它。为什么要“超过半数”而不是“全员同意”因为全员同意有两个致命问题一是任何一个节点宕机系统就无法决策这退回了单机容错模型二是你没法确定“没回复的节点是拒绝还是死机”等下去就卡死。超过半数之所以能保证安全靠的是一条很朴素的数学性质在 N 个节点的集合里任意两个“超过半数的子集”必然有交集。你可以想象一个抽屉原理把 5 个球分到两个箱子里每个箱子至少装 3 个那这两个箱子必然至少共享 1 个球。正因为任意两个多数派必然相交系统才能保证“不可能有两个提案同时胜出”——如果提案 P 已经被多数派接受提案 Q 想被另一个多数派接受它俩的交集节点会出来否决 Q 或者要求 Q 采用 P 的值。这个性质直接决定了系统的容错上限要容忍 F 个节点同时故障集群至少要 2F1 个节点。3 节点容忍 1 个故障5 节点容忍 2 个7 节点容忍 3 个。这也是为什么你在生产环境见到的一致性集群大多是奇数节点因为偶数节点只会白白增加成本并不能提升容错能力。2.3 两阶段协议的设计逻辑Paxos 的核心是两阶段协议第一阶段叫 Prepare/Promise第二阶段叫 Accept/Accepted。很多人第一眼看到这两个阶段会觉得很繁琐为什么不能直接让 Proposer 广播一个提案让所有人投票原因是在没有协调者、没有全局时钟的环境里“直接投票”无法处理并发和乱序。设想两个 Proposer 同时提出不同的值 v1 和 v2各有一半节点接受了 v1另一半接受了 v2两半都不到多数没人说得清谁赢了。更糟的是两个 Proposer 可以反复发声系统可能一直无法收敛。两阶段协议的设计目标就是给决策过程加一道“排序锁”第一阶段先探测整个集群当前的状态弄清楚 Acceptor 们是否已经接受过某个值第二阶段才真正提交。如果发现有值已经被接受过新提案就必须沿用那个老值而不是另立新值。这样即使并发发起提案系统最终只会在一个值上收敛。用一句生活化的话来说先问大家“你们谈得怎么样了”确认没有更早的结论后才提出自己的建议如果早就有结论就顺着结论走。3. 两阶段提交流程的完整推演3.1 阶段一Prepare 与 Promise 的交互细节第一阶段由 Proposer 发起。假设 Proposer 已经选好一个编号 n它会向一个足够大的多数派 Acceptor 发送 Prepare(n) 消息。这里注意它只需要发给多数派不需要广播给所有人更不需要等待所有节点回复。Acceptor 收到 Prepare(n) 时逻辑非常简单如果 n 大于它见过的最大编号就返回 Promise承诺不再接受任何编号小于 n 的提案同时把它已经接受过的、编号最大的那一个提案如果有的话附带在回复里告诉 Proposer。如果 n 小于等于它见过的最大编号就直接拒绝让 Proposer 知道自己来晚了。这个“承诺”是整个协议安全的关键。Acceptor 一旦对编号 n 许下承诺就不能再放低标准接受更小的编号。就像你在投票时不接受比最新版本更老的议案一样这保证了集群不会在同一个问题上忽高忽低地摇摆。对于 Proposer 来说它要等的是多数派 Promise只要拿到多数派它就可以进入第二阶段。如果拿不到多数派就意味着它的编号太低了需要选更大的编号重新来过。3.2 阶段二Accept 请求与值传播规则Proposer 收集到多数派 Promise 后可以开始真正的提交。这里有一个极其重要的规则问的人很多也很容易绕晕Proposer 不应该总是提自己最初想提的值。它需要检查所有 Promise 回复里捎带的“已接受提案”。如果这些回复中有人带上了一个已接受的提案那么 Proposer 必须选择其中编号最大的那个提案的值而不是自己的原始值只有当所有回复里都不存在任何已接受提案时它才可以提交自己想要的原始值。为什么必须这样举个反例假设集群里多数派已经接受了提案编号 5值 A另一个 Proposer 没注意到拿着更大的编号 6 发起 Prepare因为它收到的多数派 Promise 里恰好没有包含那个已经接受 A 的节点于是它提交了自己想提的值 B。如果这个新提案也被接受那么 A 和 B 都有望被各自的多数派接受两个值可能并存共识就失败了。Paxos 通过“必须沿用已接受值”的规则让已经胜出的值 A 不断在新的提案中延续其他 Proposer 最多只能改变提案编号无法改变值。这就是值传播是算法正确性最有魔力的地方。确定好提案内容后Proposer 把 Accept(n, v) 发送给此前回过的那些 Acceptor。Acceptor 收到 Accept 后会再次检查只要自己还没有对更大编号做过 Promise就接受提案一般会持久化这个状态并给 Learner 们发送 Accepted 通知。当某一提案被多数派接受这个值就算被集群选定了。3.3 一个完整提案的时序案例用一个 3 节点集群A、B、C来演示正常流程。节点 A 作为 Proposer想提交值 v100A 选出编号 1发送 Prepare(1) 给 B 和 C。B、C 此前没见过任何编号都回复 Promise并注明“无已接受提案”。A 收到多数派 Promise确认没有已接受提案于是把自己的值 100 绑定到编号 1 上发送 Accept(1, 100) 给 B 和 C。B、C 收到 Accept发现自己没承诺过更大编号于是接受提案并返回 Accepted 给集群中的 Learner。Learner 发现编号 1 的提案已被多数派接受于是把 v100 应用到各自状态机。再演示一个编号冲突的场景。假设 A 刚发完 Prepare(1)还没来得及发 Accept节点 B 作为另一个 Proposer 也发起 Prepare(2) 发给了 B 自己角色复用和 C。C 看到编号 2 比 1 大就更新记忆并承诺编号 2。此时 A 再发 Accept(1, 100)C 就会拒绝它因为 C 已经承诺过更大的编号。A 收到拒绝后只能重新选择编号 3再来一轮 Prepare。这就会引出一个经典问题活锁。4. Paxos 的工程化痛点与 Multi-Paxos 的演进4.1 活锁问题两个 Proposer 互踩从上面的场景可以顺出来一个很实际的问题如果 A 和 B 一直交替发起更大编号的 Prepare会发生什么A 发送 Prepare(1)B 发送 Prepare(2)A 发现被拒绝后重新发送 Prepare(3)B 发现自己编号又不够了再发送 Prepare(4…)如此循环看起来每一步都在合法地推进可集群始终没有值被最终选定。这就像两个人互相给对方使绊子谁也没法把提案落下去。这就是活锁系统没有卡死但一直在空转。原始论文里也点到了这个问题并建议工程实现中让每个 Proposer 在失败后随机退避一段时间或者干脆引入一个 Leader让集群同时只有一个活跃的 Proposer 在跑。后者几乎是所有工程化系统最终都会选择的方案也是走向 Multi-Paxos 的关键一步。4.2 Leader 机制与 Multi-Paxos 的批量优化在生产系统里几乎没人使用最原始的 Paxos 靠多个 Proposer 同时竞争而是先通过一轮 Paxos 选出唯一 Leader之后的提案都由这个 Leader 发起。Leader 的存在消灭了竞争自然也就消掉了活锁。选出 Leader 后可以做很关键的优化正常状态下只有 Leader 会发起 Accept那么在后续若干个决策里其他 Acceptor 的编号记忆基本不会被更新Leader 不必每次都为每个提案重新跑一遍 Prepare。它只需要在一开始跑一次 Prepare 确立自己的编号后面每个日志条目直接走 Accept 阶段。这样一来两阶段协议在稳定期退化成了“一条日志一轮 Accept”极大降低了消息复杂度。把多条要复制日志的决策串起来就是 Multi-Paxos 的落地形态。每条日志记录占据一个槽位Slot每个槽位需要独立运行一次 Paxos 实例目的是让所有节点对“每个槽位里放哪条日志”达成一致从而保证日志顺序一致。这也解释了为什么你看很多系统实现时日志复制链路就是一个不断生成槽位、填充日志、等待多数派确认的循环。4.3 为什么 Raft 更流行Paxos 依然是必修课聊到工程落地自然绕不开一个话题为什么市面上很多中间件选 Raft 而不是原始 Paxos原因主要在于 Paxos 论文只定义了核心共识算法但没有规定很多工程问题比如日志复制怎么组织、成员变更怎么做、快照怎么管理、Leader 怎么轮换。各个系统实现 Paxos 时各有各的处理方式理解成本很高。Raft 把这些问题一揽子写清楚了用任期、日志匹配、选举限制这些直观概念覆盖了完整链路工程团队实现起来更快也更好排查问题。但这不代表 Paxos 可以被跳过去。Raft 也好其他共识协议也罢本质上都在围绕 Paxos 点明的那些底层约束打转你理解了两阶段和多数派就能看懂很多系统“为什么这么设计”。比如 Raft 里的选主本质上就是一个简化版的共识过程日志复制的多数派确认也几乎就是 Multi-Paxos 的翻版。用一句话说Paxos 是“共识问题的公理”Raft 是“一套方便工程落地的简洁解法”。5. Paxos 在分布式系统高可用性保障中的落地实战5.1 典型应用场景配置中心、分布式锁与元数据存储Paxos 本身不是一个拿来即用的软件而是一种算法范式真正接触到的通常是各种实现了类 Paxos 或 Raft 的中间件和存储系统。但理解它的原理后你会立刻看懂这些产品为什么在高可用性上能交出漂亮的答卷。配置中心是特别直观的例子。生产配置是全局状态不能丢也不能错常见做法是把这个状态放到 3 或 5 个节点上任何配置变更都走一遍共识协议等多数节点持久化成功才算生效。这样即便有两台节点同时宕机剩余节点依然能组合出多数派新配置可以继续发布读请求也永远能看到一份一致的最新配置。分布式锁是另一个经典场景。锁的本质是“同一个时刻只能有一个客户端拿到锁”很多笨拙实现就是存一个 key 加上超时时间主节点一挂整个锁服务就不可用。而基于共识协议的实现会把锁的获取和释放操作当作一条条日志复制到多数派节点任何拿到锁的数据记录都经过多数派确认这样即使某个节点临时失联锁状态也不会丢或出现双活。元数据存储也有类似需求。很多分布式存储系统管理数据分片位置、副本列表、Schema 信息这些元数据自身必须满足强一致和可用性它们通常落在独立的共识组里。一旦某个元数据节点挂了其余节点还能继续对元数据变更达成一致整个存储集群的对外服务不受影响。可以说只要系统里存在“不能丢、不能错、不能因为单点故障就不可用”的全局状态共识算法就是支撑它的那根柱子。5.2 集群规模、容错能力与性能的权衡规划一个共识集群时实际要算的不是“越多越好”而是“最少多少个节点能满足容错需求”。前面说过容忍 F 个节点故障需要 2F1 个节点具体对应关系可以用一张表列清楚集群总节点数 N可容忍故障数 F多数派 Quorum 大小312523734945工程上最常见的是 3 节点和 5 节点。3 节点能容忍 1 个故障已经能覆盖大多数单机房场景5 节点能容忍 2 个故障适合要求稍高的核心链路。7 个以上节点虽然容错更多但消息量跟着涨每个提案都要和 4 个节点交互网络开销变大故障域也变得更大。所以不是节点越多系统越高可用高可用需要的其实是“设计上的冗余部署上的故障域隔离”把节点分散到不同机架甚至不同机房比单纯堆数量有效得多。这里还值得提一个性能细节多数派确认的延迟取决于最慢的那个 Acceptor 的响应时间。也就是说集群里有一台机器磁盘抖动整个写入链路都会被拖慢。所以高可用集群的维护重点其实是关注慢节点而不是只关注挂掉的节点。5.3 故障恢复、网络分区与脑裂的真实表现我们落回最开始的故障场景用 Paxos 的逻辑推演一遍。3 节点集群 A、B、CA 突然宕机。由于 B、C 仍然构成了一个多数派新的决策照常进行业务无感。A 恢复后它发现自己日志落后会通过 Learner 或者专门的日志追赶机制同步缺失的记录等追平之后再重新参与投票。整个过程不会出现两个版本的数据。再看网络分区假设集群被切成两个部分一边是 A一边是 B、C。B、C 是多数派所以它们可以继续接受提案A 是少数派虽然也发起了自己的提案但因为无法凑齐多数派任何请求都会卡在等待 Promise 或者 Accept 的阶段一直等到分区恢复。这里注意旧主如果落在少数派那边它即使还在运行也无法提交有效决策这正好堵住了脑裂导致双主写入的路子。等网络恢复后少数派的节点会看到多数派已经选定的新日志于是放弃自己的旧提案同步数据重新归队。所以 Paxos 类系统在分区面前的行为是很好预测的多数派继续服务少数派等待恢复并最终追平。这也是它的高可用性最迷人的地方不需要人为判断谁对谁错协议自己就能把秩序稳定下来。多数派继续服务分区时多数派能够正常提交新的日志条目。少数派停止决策旧主在少数派一侧时无法形成多数派提案被阻塞。恢复后自动追平分区合并后少数派节点同步最新状态并重新参与决策。6. 从原理到工程实操经验与踩坑记录6.1 实现时最容易忽略的细节坑先说进过几次坑才真正想明白的几条经验。第一个坑是持久化时机。Acceptor 在返回 Promise 之前必须把这个“最大编号承诺”持久化到磁盘。很多初版实现只存在内存里以为问题不大结果节点一重启记忆清零又向旧编号的提案点头直接把安全保证破坏掉了。更准确地说所有影响安全性判断的状态都必须在响应消息之前落盘顺序不能反。第二个坑是 Prepare 回复丢“值”。有些实现者为了简化在 Promise 消息里只回显编号不回显值结果 Proposer 无法判断自己是否应该沿用已接受的值。这会直接导致两个不同值被先后接受非常危险。凡是 Acceptor 保存了已接受提案就必须把提案的完整内容在 Promise 里带回去。第三个坑是 Leader 的频繁选举。Leader 刚选出就因网络抖动丢失心跳另一个节点又抢占新 Leader日志经常会互相覆盖性能也会明显劣化。实践中需要调大心跳超时时间的波动范围让 Leader 在短期抖动时不要被轻易换掉集群才能保持稳定。6.2 观察与调试一致性系统的手段调试这类系统一定要把每类消息的核心字段打出来提案编号、提案值、目标槽位、发送方和接收方。日志里看到 Prepare 被拒绝要能快速定位是谁发起了更大的编号看到 Accept 被忽略要检查 Acceptor 的已经承诺编号是不是被顶得过高。对一致性系统排障来说日志就是状态机的投影猜来猜去是最费时间的。想验证一个集群在分区情况下是否安全可以实际制造网络隔离来观察比如通过访问控制规则丢弃节点之间的部分网络包。这种实验建议在测试环境跑重点看三件事多数派是否还能正常提交、少数派是否如预期阻塞、网络恢复后节点是否能自动追平日志。能连续通过这类演练这套集群才算真正具备可以上线的高可用能力。另外每次做故障演练时可以问自己一个问题最后成功提交的日志是哪条它获得了哪些节点的确认哪些节点不在这个多数派里把这个问题弄清楚了对整个协议的把握就会上升一个台阶。6.3 学习路径建议如果你正在学共识算法我的建议是别一上来就死磕论文里的不变量证明很容易绕晕。可以先做这么几步第一步把“两个多数派必有交集”当成一个数学公理记清楚想明白它为什么能防止双主。第二步自己画一张时序图把正常提案、编号冲突、值传播三个场景各推演一遍尤其要体会“值必须沿用”那条规则。第三步看一个基于类 Raft 的开源实现把选主、日志复制、多数派确认这几个模块在代码里对应上。第四步跑一个简化版的 KV 复制例子主动杀掉其中一个节点看看写入是否仍然可用再两个节点同时杀掉看看系统如何停止决策。如果你已经能清晰说出“旧主为什么不能继续写”“多数派接受后 Learner 如何补日志”“节点重启后靠什么遵守旧承诺”这三个问题那么 Paxos 你想不读懂都难。而这份对一致性的理解几乎可以迁移到任何分布式系统的高可用设计里去。我个人在实际操作中的体会是难度不在两阶段的“阶段”本身而在工程化过程中那些看不见的细节——各自角色要持续持久化状态、编号分配要全局唯一且稳定、日志追赶要设计成可中断继续、Leader 切换要有足够礼貌的心跳超时。如果让我总结一条最实用的建议那就是把每个角色维护的记录当成一个真实的状态机来对待所有消息都围绕它的持久化状态决策不要为了性能去跳过任何一步安全写入。再分享一个小技巧测试高可用时直接用断电或者禁网的方式杀节点避免优雅关机的假象这样能把日志持久化、超时恢复这些真实场景一次性暴露出来。把这个最内核的共识问题想清楚再看任何“类 Paxos”或者“类 Raft”的系统都会有一种庖丁解牛的感觉。

Paxos 共识算法：从多数派原理到高可用架构落地

相关推荐

从0到1搭建AI销售机器人：人机协同与落地实践指南

ThinkPHP响应式双语设备官网源码：部署与二次开发避坑指南

2024开发者AI实践指南：大模型、Agent与RAG的落地之道

更多资讯

WorkBuddy：嵌入操作系统的AI办公引擎

从零实现Transformer：核心原理、代码实操与踩坑经验

语音控制智能家居：从Demo到稳定可用的端到端实现与避坑指南

CUA-Skill实战：AI Agent驱动GUI自动化的技能框架

ArcGIS REST API 实践指南：端点选型、参数与排查技巧

非合作博弈下的居民负荷分层调度与双层鲸鱼算法求解

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？