解码分布式共识：从Paxos到Raft到EPaxos的一致性算法谱系与演进

一、FLP 不可能定理：共识的边界

在分布式系统的诸多挑战中，共识问题（Consensus Problem）无疑是最核心的：多个独立的进程如何对某个值达成一致？1985年Fischer、Lynch和Patterson提出的FLP不可能定理证明：在异步系统中，即使只有一个进程崩溃，也不存在确定性算法能解决共识问题。这一定理指明了所有实用一致性算法都必须引入某种同步假设或随机化手段来绕过FLP的限制。

二、Paxos：理论的丰碑

Paxos将共识分解为Prepare/Promise和Propose/Accept两个阶段，通过提案编号的单调递增构建全局序关系。Multi-Paxos则扩展为日志中每个槽位的共识实例，将Phase 1优化为一次性的领导选举，使每条日志1-RTT发送成为可能。Google的Chubby和Spanner、Apache ZooKeeper的ZAB协议本质上都是Multi-Paxos的变体。然而Paxos的晦涩难懂始终是工程落地的障碍——论文中用古希腊城邦故事阐释算法，门槛极高。活锁问题则需要选唯一的Distinguished Proposer来规避。

三、Raft：工程可理解性的胜利

Raft的核心设计哲学是可理解性——将共识分解为Leader选举、日志复制和安全性三个独立子问题。Term机制作为逻辑时钟，随机超时选举（150-300ms）降低选票分裂概率。Leader完整性性质保证：如果某日志项在某Term被提交，则必然存在于所有更高Term的Leader日志中。联合共识（Joint Consensus）机制在配置变更期间同时获得新旧配置多数派确认，避免双重领导风险。etcd、TiKV、CockroachDB、Consul等系统都采用了Raft。

四、EPaxos：打破串行化的枷锁

EPaxos（SOSP 2013）通过构建依赖图（Dependency Graph）实现非领导型共识：每个提案附带它感知到的并发操作依赖集合，节点按依赖拓扑序恢复执行。Fast Path（无冲突）1-RTT提交，Slow Path（冲突检测）3-RTT恢复协议。在低冲突负载下吞吐比Multi-Paxos高3.5倍以上。后续Caesar（NSDI 2020）预测冲突，CURP（SOSP 2021）利用持久化内存加速。

五、现代进展与选型指南

Parallel Raft保留Raft可理解性的同时实现非冲突并行提交。RDMA技术推动Direct Paxos等硬件加速协议将延迟降至微秒级。选型建议：企业内部用Raft（etcd/ZooKeeper），跨地域低延迟写入考虑EPaxos变体，金融级一致性用Paxos+TrueTime（Spanner模式）。

六、未来展望

一致性算法研究正朝AI辅助调优、异构硬件融合、形式化验证量产化方向推进。正如Lamport所言：分布式系统就是系统中一个组件出现故障，而你却不知道哪个组件出现了故障的系统。一致性算法，正是我们在不可靠世界中锚定可靠的基石。