分布式共识算法的性能极限：Paxos、Raft与EPaxos延迟和吞吐的系统性对比分析

一、"为什么选了Raft，日志复制延迟还是降不下来？"

在TiKV和etcd等分布式系统中，Raft是默认的共识算法。但当我们试图在跨可用区部署中进一步优化延迟时，发现Raft的"强主模型"存在理论上的性能天花板——Leader必须串行处理所有写请求。无论你增加了多少节点、提高了多少网络带宽，写入吞吐受限于单Leader的处理能力。

这引出了一个根本性的架构问题：在分布式共识算法中，Paxos/Raft/EPaxos到底差在哪？它们的性能极限分别在什么场景下被触及？选型时应该基于什么因素做决策？

二、三类共识算法的核心差异

Raft：以"易懂"为核心设计目标。强主模型——所有写入通过Leader串行处理，协议分为Leader选举和日志复制两个阶段。正常运行时，一次写操作需要1次RTT（Leader → 多数Follower → Leader确认）。性能天花板来自单Leader的CPU处理能力和网络带宽。

Multi-Paxos：Raft的精神前身。在实际工程实现中（如Google的Chubby、腾讯的PhxPaxos），Multi-Paxos的优化版本与Raft性能接近——都引入Leader角色来简化日志复制。区别在于Paxos的"无Leader选主"理论上更灵活（任何时候都可以提议新提案），但实现复杂度显著更高。

EPaxos：试图突破单Leader瓶颈的"无主"共识算法。它的核心创新是依赖图——每个写请求记录自己的依赖关系，构建一个有向无环图。无冲突的写操作可以并行提交（快速路径，1RTT），有冲突的写操作需要额外协调（慢路径，2RTT）。

三、性能对比的关键指标

写入延迟：在单数据中心低延迟网络（RTT<1ms）中，Raft和Multi-Paxos的P50写入延迟约0.5~1ms，EPaxos的快速路径约0.5ms、慢路径约1.5ms。在跨数据中心（RTT=50ms）场景中，Raft的1RTT延迟为50ms，EPaxos在理想情况下的快速路径也是50ms——跨数据中心的延迟主要受光速限制而非协议限制。

写入吞吐：这是EPaxos的优势所在。在冲突率低的场景下，EPaxos可以实现近似线性的写入扩展——因为每个节点都可以独立处理写请求。Raft受限于单Leader，写入吞吐在Leader CPU达到瓶颈后就不再增长。在16节点集群的测试中，冲突率<5%时EPaxos的吞吐是Raft的3~5倍；冲突率>20%时两者的差距缩小。

读操作：Raft可以提供线性一致性读（通过ReadIndex或LeaseRead），延迟约0~0.5ms。EPaxos的线性一致性读需要更复杂的协调，是一个明确的弱点。

四、选型决策框架

选择Raft：团队对分布式共识算法不熟悉（Raft的易懂性降低实现错误风险）、大部分操作是读（读操作简单高效）、写吞吐不需要超过单Leader能力、系统规模在5~7节点以内。

选择Multi-Paxos：有高性能的Paxos参考实现（如腾讯的PhxPaxos）、需要更灵活的配置恢复策略、团队有Paxos的实施和维护能力。

选择EPaxos：写入吞吐是主要瓶颈（单Leader不足以支撑）、冲突率低（大部分写操作涉及不同Key）、可以接受更高的实现和维护复杂度、读负载可以通过缓存层解决。

五、总结

分布式共识算法的选择不是"技术先进度"的比较，而是"场景匹配度"的权衡。Raft的简单性降低了实现和维护风险，在大多数场景下性能已经足够。EPaxos在特定场景（低冲突高写入吞吐）下提供了理论上的性能优势，但成本更高。

对于正在选型的团队，建议先用Raft——不是因为Raft是"最好"的，而是因为Raft的"最不容易出错"。只有在明确证实写入吞吐已成为瓶颈、且通过分片等架构手段无法解决时，才考虑EPaxos等更复杂的方案。在分布式系统中，"能做对"比"做得好"重要得多。