前言
在现代分布式系统中，多个节点如何就某个“真相”达成一致，是构建可靠系统的核心问题之一。无论是分布式数据库、共识引擎，还是一致性协调服务，**一致性协议（Consensus Protocol）**都是底层基石。Paxos 正是其中最经典、最具理论价值的协议之一。
定义
wiki 定义如下：
Paxos is a family of protocols for solving consensus in a network of unreliable or fallible processors.
一句话：Paxos 是一种在分布式系统中实现多个节点就某个值达成一致的共识算法。
工作原理
一句话：通过多个阶段的投票与提议，使一组节点就某个提案达成共识，即便其中一部分节点失败也能保障正确性。
Paxos 通常由三个角色组成：
- Proposer（提议者）：发起提案。
- Acceptor（接受者）：负责投票，决定提案是否被接受。
- Learner（学习者）：了解哪个提案被通过（已达成共识）。
基本 Paxos 流程包括两个阶段：
- Prepare 阶段：Proposer 向 Acceptors 发出准备请求（编号 N），Acceptors 承诺不接受编号小于 N 的提案。
- Accept 阶段：如果 Proposer 收到大多数 Acceptors 的响应，它就发出“接受”请求，包含编号 N 和提案值 V，Acceptors 再次响应是否接受。
当一个提案被多数 Acceptors 接受，则认为“达成共识”。
属性与指标
Paxos 关注以下关键属性：
-
安全性（Safety） 永远不会有两个不同的值被同时决定。
-
活性（Liveness） 只要大多数节点存活且网络可靠，最终一定可以达成共识。
-
故障容忍性 可以容忍 少数派节点故障，一般要求超过半数节点正常。
-
最小消息轮次 理论上最少两轮（Prepare 和 Accept），但实践中常需更多轮重试。
-
吞吐量与延迟 原始 Paxos 性能较差，主要受限于同步流程和多数派写入。
-
Leader 角色（在优化版本中） 通过引入 Leader 可以避免多 Proposer 竞争造成的冲突。
类型
Paxos 协议家族
-
Basic Paxos 原始论文提出的版本，理论为主，不易实现。
-
Multi-Paxos 实用版本，引入长期 Leader，提高性能，支持多个提案序列。
-
Fast Paxos 减少消息轮数，但需要更多副本。
-
Cheap Paxos 使用一个可靠磁盘代替一个投票节点，降低资源成本。
-
Disk Paxos / Byzantine Paxos 面向特殊场景如非信任环境或持久存储的版本。
-
Paxos Made Simple / Paxos Made Live 简化版及 Google 实现版本（用于 Chubby 锁服务）。
应用与场景
| 场景 | 是否适用 Paxos | 说明 |
|---|---|---|
| 分布式协调服务（如锁） | ✅ | 需要强一致性 |
| 主从选举 | ✅ | 多节点选 Leader |
| 高可用数据库写入 | ✅ | 保证写入唯一顺序 |
| 最终一致系统（如 Dynamo） | ❌ | 容错性优先，不强一致 |
| 区块链共识（如 PoW） | ❌ | 使用更适合开放网络的算法 |
Paxos 与程序关系
-
编程实现复杂 尽管逻辑看似清晰，实现细节多，处理边界条件困难。
-
推荐使用成熟框架 如 etcd（Raft 实现）、ZooKeeper（Zab 实现）等已经封装共识过程。
-
学习成本高 Paxos 理论晦涩，但是理解其他共识协议的基础。
-
对系统延迟敏感 多数派写入和消息往返轮次使 Paxos 对网络质量有较高要求。
常见使用 Paxos 的系统
- Google Chubby：分布式锁服务，用于 GFS 和 Bigtable。
- Spinnaker：LinkedIn 构建的 Paxos-based 数据库。
- Shepard（AWS）：EC2 实例状态一致性维护系统。
- RAMP Transactions：使用 Paxos 保证分布式事务原子性。
- OpenReplica：通用 Paxos 实现框架。
拓展阅读
如果你对 Paxos 感兴趣，以下内容可以进一步学习：
- Raft 101（比 Paxos 更易于实现）
- Viewstamped Replication
- Zab Protocol（ZooKeeper）
- Byzantine Fault Tolerant Paxos（如 PBFT）
评论