共识算法是分布式系统的“最高宪法”。当你听到区块链、分布式数据库或容灾架构时，背后总有一个能够容忍节点崩溃与网络割裂、却依然保证数据一致性的神奇协议。本文用口语化 + 结构化笔记带你一口气读懂 2PC、3PC、Paxos、Raft、Bully、Gossip、PoW、PoS 等关键词的相同与不同之处，以及如何在现实选型中少走弯路。
两阶段提交：2PC 的双刃剑
关键词：同步阻塞、单点故障、事务一致性
- 投票阶段（Voting）
协调者问所有节点：同不同意提交？ 提交阶段（Commit）
- 全部回复“同意”→一起提交；
- 有任一“反对”→回滚。
2PC 简单直白，却天生怕“投票后失联”。协调者掉链子，全集群会阻塞——这就是 fail-stop。再加上需要100 %节点全票赞成，容错性为零。任何运维踩过坑的 DBA 都知道，当天花板级别的交易一致性需求遇到低容错，2PC 只能望而却步。
三阶段提交：3PC 把“阻塞”拆开两步
关键词：PreCommit、超时机制、网络分区
- 在 2PC 的 Commit 之前新增 PreCommit 缓冲带：先把投票结果再广播一次，各节点确认“我没抖”。
- 若协调者崩溃，节点可凭最后一次收到的 PreCommit 成败样例，主动回滚或提交，避免永久阻塞。
- 致命缺点：遇网络分区还是无解。一半节点看到 PreCommit，一半没看到，就会出现“双主”危机，决策冲突。
Paxos：学术界的共识圣经
关键词：Quorum、半数投票、数学证明
Paxos 把投票权拆成两组角色：Proposer（提议）+ Acceptor（投票）。
- 至少 Quorum = N/2 + 1 的节点同意才算真正的共识。
- 论文本身极其晦涩，却奠定了多副本数据库的容错基石：宕机少于半数的节点不影响执行。
👉 一文看懂 Paxos 的 3 分钟要领，为 Raft 打下地基
Raft：把 Paxos 白话成“跟随法则”
关键词：Leader、Term、日志同步、奇数节点
一条日志，一个 Leader
- Follower 收心跳→崇拜老大。
- Leader 掉线→Follower 变成 Candidate，用“我 ID 最新”拉票选举新任期 Term。
过半即胜
- 写入日志须拿到
Quorum过半的副本确认——不允许 =50 %，否则脑裂风险骤增。
- 写入日志须拿到
节点数目魔法
- 3 节点：挂 1 台不跪。
- 4 节点：仍只能挂 1 台，投入产出比负收益。
- 5 节点：挂 2 台稳如老狗。
Raft 本是工程派的福音，K8s、Etcd、Consul 都把 Raft 当默认骨干，易读易改，却依然不防拜占庭节点伪造消息。
Bully：比“嗓门”大
关键词：ID 最大、Leader 选举、瞬时故障恢复
类似 Raft 的主从切换，但选举规则粗暴：谁的节点编号最大谁当王。优点是代码行数极少，缺点是频繁主从切换时可能造成“选举风暴”，ID 低的节点永远抢不过别人，用户体验一落千丈。
Gossip：流言蜚语的传播学
关键词：病毒式扩散、去中心化、最终一致性
- 每个节点周期性地把最新消息推给 k 个朋友，朋友再二次传播。
- 无需中心协调，配合 TTL 和幂等写入可做到全网最终一致性。
- 常见场景：会员发现、区块链节点发现、灾备数据复制。
缺点是可预测性差，你很难评估“消息何时铺向90 %节点”。
PoW：把计算当选票
关键词：哈希、挖矿、抗女巫攻击、能耗高
- 比特币模式：区块+随机数 → 哈希前缀足够零才算工作量。
- 全网算力把最长链当事实，写入顺序不可变。
- 拜占庭容错可达 33 %（1/3 以下算力修改无效），但能源消耗是常态吐槽。
👉 点击探索怎样靠 GPU 退一步、电力让世界进一步
PoS：股权即权力
关键词：质押、暴力惩罚、节能、出块概率
- 以太坊 2.0 把“算力”换成“质押 32 ETH”换取验证者席位。
- 不诚实：动态罚没部分保证金；称职者：利息奖励。
- 彻底砍掉巨额电费，PoS 的能耗约为同规模 PoW 网络的 1 % 左右。
- 出块概率随机且可预测（每 12 秒 1 个 slot），同时通过 Finality Gadget 进一步固化共识。
如何在三大场景选共识算法？真实案例拆解
| 场景 | 算法 & 配置 | 主要权衡点 |
|---|---|---|
| 关系型事务库 | 2PC+本地持久化 | 强一致但阻塞，适合同城三机房高可用 |
| 分布式缓存 | Raft+3 节点奇数集群 | 易部署、容忍 1 节点故障 |
| 公链公项目 | PoS+128 共识委员会 | 兼顾能耗、去中心化与性能 |
FAQ：十分钟解决 80 %的疑问
Q1：为什么 Raft 推荐奇数个节点而不是偶数个？
奇数时挂掉的节点数上限不会因为加 1 台而变多，反而能让 Quorum > N/2 永不尴尬。
Q2：3PC 的网络分区为何比 2PC 更容易暴露裂缝？
因为 PreCommit 把“全局统一”这件事检查了两遍；一旦分裂，两边的各自提交票仓数目差距将立刻现形。
Q3：小型团队用 PoW 自建链会有哪些问题？
算力稀缺 → 51 % 攻击成本远低，攻击链分分钟反杀主链。PoW 最好“大流量带来大算力”，否则得不偿失。
Q4：DBC（数据银行云）要 5 个 9 的可用性，怎么配 Raft？
5 节点跨 AZ 部署，允许 2 网停机，另加快照+温备，实现分钟级故障恢复。
Q5：Gossip 在多活卖票业务中行不行？
不行。消息经济舱旅客难免“座位重分配”，必须上位层加幂等号和业务锁才能保证不会超卖。
Q6：PoS 质押就能拿奖励，会不会形成“富者愈富”悖论？
一定程度上会；解决思路是质押上限+随机抽签委员会制（以太坊 2.0 现有模型），降低马太效应。
写在最后
从 1980 代的 2PC 到 2020 后的 PoS，所有共识算法的演进都在回答两大问题：
- 在 网络不可靠、节点爱掉线 的世界里如何共同信任同一份数据？
- 把这种信任的代价压得足够低，让普通开发者愿意落地。
读完本文，你不仅能一眼区分 2PC 与 3PC、Raft 与 Paxos、PoW 与 PoS 的差异，还能在工作面试或架构评审里自信抛出 Quorum、脑裂、拜占庭容错 等行话。愿你下次遇见“到底选哪个共识算法”的灵魂提问时，能够用一条 Markdown 链接甩给对方：“看这篇就够了”。