下面把大家常混在一起的「Paxos / Raft / Quorum」三件套放在一张表里说清楚：它们到底解决什么问题、核心流程、容灾能力、性能特点以及写代码时的落地难度。读完就能快速判断该选谁。
| 维度 | Quorum | Raft | Paxos |
|---|---|---|---|
| 定位 | 最朴素的「多副本投票」策略，保证「我能读到最新写入」即可，不追求所有节点状态完全一致。 | 工程化的「共识（consensus）」算法，目标：日志在所有节点按同样顺序落地，强一致。 | 理论化的「共识」算法，目标同 Raft，但更抽象、更通用。 |
| 核心思想 | 配置三参数：N（副本数）、W（写成功票数）、R（读成功票数）。只要 W+R>N，读写必有交集，从而读到最新值。 | 先选出一个 Leader，所有写请求走 Leader；日志按 Term+Index 顺序复制到多数派后提交。 | 无固定 Leader，通过两阶段（Prepare/Accept）+ 全局递增提案编号竞争，使「同一个提案编号、同一个值」被多数接受。 |
| 一致性级别 | 最终一致或线性一致（要看 W/R 怎么配）。标准配置下比后面两个弱。 | 严格的线性一致（Linearizable）。 | 严格的线性一致。 |
| 最大容错节点数 | f = N − min(W,R)（可调）。典型 W=R=⌈N/2⌉+1 时，f = ⌊(N−1)/2⌋，与 Raft/Paxos 相同。 | ⌊(N−1)/2⌋ | ⌊(N−1)/2⌋ |
| 网络分区表现 | 通过 W+R>N 保证最多只有一个分区可写，但需客户端配合重试，易出「短暂双写」风险。 | Leader 只在含多数派的分区工作；另一半分区自动重新选主，恢复后日志自动对齐，无脑裂。 | 任何含多数派的分区都能推进提案，但需额外机制防活锁；理论上最灵活，实现复杂。 |
| 吞吐 | 受 W/R 影响大；W 越小越快，但一致性越弱。 | Leader 把请求批量串行下发，吞吐通常高于另外两者。 | 原版两阶段竞争大，吞吐一般；Multi-Paxos 选主后接近 Raft。 |
| 延迟 | 读延迟低（R 可配 1），写延迟随 W 线性增加。 | 一次写需 1 次 RTT（Leader→多数派）；读走 Leader 也只要 1 次 RTT。 | 原版两阶段 2 RTT；Multi-Paxos 稳定后 1 RTT。 |
| 实现复杂度 | 最低：计数器+版本号即可，无选主、无日志对齐。 | 中等：状态机（Leader/Follower/Candidate）、日志匹配、快照、成员变更，资料/现成库极多。 | 最高：竞争提案、活锁、证明正确性难；工业级实现少，调试痛苦。 |
| 生态&开源 | 少，一般嵌在数据库或区块链里（InfluxDB、Quorum 链）。 | 极丰富：etcd、Consul、TiKV、CockroachDB、KRaft…几乎成为云原生标配。 | 中等：Chubby、Spanner、phxpaxos、paxosstore，多为大厂自研，二次开发门槛高。 |
| 适用场景 | 对一致性要求一般、希望简单多副本+读写可调：分布式缓存、时序数据库、区块链节点同步。 | 需要「开箱即用」的强一致、高可靠、易维护：服务发现、分布式 KV、NewSQL、消息队列元数据。 | 对正确性要求极高、愿意投入人力做形式化验证或自研基础设施：金融核心、Google 级全球数据库。 |
一句话总结
- 想“马上能用”且要「强一致」——直接上 Raft，资料多、坑少。
- 只要求「别丢数据」「读写可调」且开发量最小——用 Quorum 策略即可。
- 需要「理论上最严谨」或自定义变种——再去啃 Paxos 家族。
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
