前言

在现代分布式系统中，多个节点如何就某个“真相”达成一致，是构建可靠系统的核心问题之一。无论是分布式数据库、共识引擎，还是一致性协调服务，**一致性协议（Consensus Protocol）**都是底层基石。Paxos 正是其中最经典、最具理论价值的协议之一。

定义

wiki 定义如下：

Paxos is a family of protocols for solving consensus in a network of unreliable or fallible processors.

一句话：Paxos 是一种在分布式系统中实现多个节点就某个值达成一致的共识算法。

工作原理

一句话：通过多个阶段的投票与提议，使一组节点就某个提案达成共识，即便其中一部分节点失败也能保障正确性。

Paxos 通常由三个角色组成：

  1. Proposer（提议者）：发起提案。
  2. Acceptor（接受者）：负责投票，决定提案是否被接受。
  3. Learner（学习者）：了解哪个提案被通过（已达成共识）。

基本 Paxos 流程包括两个阶段：

  • Prepare 阶段：Proposer 向 Acceptors 发出准备请求（编号 N），Acceptors 承诺不接受编号小于 N 的提案。
  • Accept 阶段：如果 Proposer 收到大多数 Acceptors 的响应，它就发出“接受”请求，包含编号 N 和提案值 V，Acceptors 再次响应是否接受。

当一个提案被多数 Acceptors 接受，则认为“达成共识”。

属性与指标

Paxos 关注以下关键属性：

  1. 安全性（Safety） 永远不会有两个不同的值被同时决定。

  2. 活性（Liveness） 只要大多数节点存活且网络可靠，最终一定可以达成共识。

  3. 故障容忍性 可以容忍 少数派节点故障，一般要求超过半数节点正常。

  4. 最小消息轮次 理论上最少两轮（Prepare 和 Accept），但实践中常需更多轮重试。

  5. 吞吐量与延迟 原始 Paxos 性能较差，主要受限于同步流程和多数派写入。

  6. Leader 角色（在优化版本中） 通过引入 Leader 可以避免多 Proposer 竞争造成的冲突。

类型

Paxos 协议家族

  1. Basic Paxos 原始论文提出的版本，理论为主，不易实现。

  2. Multi-Paxos 实用版本，引入长期 Leader，提高性能，支持多个提案序列。

  3. Fast Paxos 减少消息轮数，但需要更多副本。

  4. Cheap Paxos 使用一个可靠磁盘代替一个投票节点，降低资源成本。

  5. Disk Paxos / Byzantine Paxos 面向特殊场景如非信任环境或持久存储的版本。

  6. Paxos Made Simple / Paxos Made Live 简化版及 Google 实现版本（用于 Chubby 锁服务）。

应用与场景

场景 是否适用 Paxos 说明
分布式协调服务（如锁） ✅ 需要强一致性
主从选举 ✅ 多节点选 Leader
高可用数据库写入 ✅ 保证写入唯一顺序
最终一致系统（如 Dynamo） ❌ 容错性优先，不强一致
区块链共识（如 PoW） ❌ 使用更适合开放网络的算法

Paxos 与程序关系

  1. 编程实现复杂 尽管逻辑看似清晰，实现细节多，处理边界条件困难。

  2. 推荐使用成熟框架 如 etcd（Raft 实现）、ZooKeeper（Zab 实现）等已经封装共识过程。

  3. 学习成本高 Paxos 理论晦涩，但是理解其他共识协议的基础。

  4. 对系统延迟敏感 多数派写入和消息往返轮次使 Paxos 对网络质量有较高要求。

常见使用 Paxos 的系统

  1. Google Chubby：分布式锁服务，用于 GFS 和 Bigtable。
  2. Spinnaker：LinkedIn 构建的 Paxos-based 数据库。
  3. Shepard（AWS）：EC2 实例状态一致性维护系统。
  4. RAMP Transactions：使用 Paxos 保证分布式事务原子性。
  5. OpenReplica：通用 Paxos 实现框架。

拓展阅读

如果你对 Paxos 感兴趣，以下内容可以进一步学习：

  • Raft 101（比 Paxos 更易于实现）
  • Viewstamped Replication
  • Zab Protocol（ZooKeeper）
  • Byzantine Fault Tolerant Paxos（如 PBFT）