分布式系统【三、Paxos 算法与分布式一致性协议详解】

Paxos 算法与分布式一致性协议详解

系列专题第三篇 · 分布式系统基础指南

---

一、引言

在 CAP 定理中我们提到，如果系统选择 一致性 © 和 分区容忍性 §，就会牺牲部分可用性。
那么，如何在分布式系统里实现「一致性」？

这就是 共识协议 (Consensus Protocol) 要解决的问题。
最经典、最有影响力的共识算法就是 Paxos，由 Leslie Lamport 在 1990 年代提出，被誉为「分布式一致性算法的基石」。

---

二、Paxos 的目标

在分布式系统中，多个节点要对某个值（如日志条目、配置参数、领导者选举结果）达成一致。
即使部分节点宕机、消息丢失，系统仍然要保证：

1. 一致性 (Consistency)：不会出现不同节点对同一事务做出不同决定。
2. 有效性 (Liveness)：在网络正常的情况下，最终一定能达成决定。

---

三、Paxos 的核心角色

Paxos 把节点分成三类角色（一个节点可同时承担多个角色）：

• Proposer（提议者）：提出一个值，想让大家达成一致。
• Acceptor（接受者）：对提议进行投票表决，结果由多数派决定。
• Learner（学习者）：学习最终达成的结果，用于系统对外提供服务。

---

四、Basic Paxos 协议流程

Paxos 分为两个阶段：

阶段 1：Prepare 阶段

1. Proposer 选择一个全局唯一的提案编号 n，向 Acceptor 发送 Prepare(n) 请求。

2. Acceptor 收到后：

   • 如果 n 大于其已承诺过的最大编号，则承诺不再接受比 n 小的提案。
   • 返回已接受的最大编号提案（如果有的话）。

阶段 2：Accept 阶段

1. Proposer 收集到多数 Acceptor 的响应后，选择：

   • 若某些 Acceptor 已经接受过提案，则使用编号最高的那个提案的值。
   • 否则，使用自己最初的值。

2. Proposer 发送 Accept(n, value) 请求给 Acceptor。

3. Acceptor 接收到请求，如果 n 不小于自己承诺的编号，则接受该提案。

4. 一旦多数 Acceptor 接受了某个提案，值即被确定。

---

五、Paxos 的性质

• 安全性 (Safety)：
  即使网络延迟、重复消息、节点宕机，也不会产生冲突的结果。

• 活性 (Liveness)：
  在正常情况下，协议可以继续推进，最终产生结果。

• 容错性 (Fault Tolerance)：
  Paxos 在 2F+1 个节点中，能容忍最多 F 个节点失效。
  例如，5 个节点能容忍 2 个故障。

---

六、Multi-Paxos

Basic Paxos 只能决定一个值（一次共识）。
在实际系统中，需要决定多个值（如日志序列）。

1. Multi-Paxos 的改进

• 通过选举 Leader，由 Leader 统一发起提案，减少 Prepare 阶段的开销。
• 一旦 Leader 稳定，后续提案只需执行 Accept 阶段。

2. 应用场景

• Google Chubby（分布式锁服务）
• Etcd、Consul（分布式配置存储）
• HDFS NameNode HA

---

七、Paxos 的不足与演进

虽然理论完备，但 Paxos 在工程上有几个问题：

• 实现复杂，难以在工业界直接使用。
• 消息量多，效率较低。
• 读写性能差，尤其是在领导者频繁切换时。

因此，业界衍生出更实用的变种：

• Raft：比 Paxos 更易理解，应用广泛（Etcd、Consul）。
• Zab：ZooKeeper 的一致性协议，类似 Multi-Paxos。

---

八、总结

• Paxos 是分布式一致性理论的基石，保证了多个节点之间对值达成一致。
• 核心思想：多数派投票、承诺机制、两阶段提议。
• 工业界大多使用 Multi-Paxos 或改进算法（Raft、Zab） 来实现高效一致性。
• 理解 Paxos，不仅是学习分布式的基础，也是理解后续各种协议（Raft、Zab、PBFT）的前提。