分布式一致性协议有哪些

🔥 2025年Java面试宝典网盘地址：
https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g（提取码：9b3g）
（面试前刷一遍，通过率提升80%）

面试鸭返利网

作为一个程序员，咱们都知道分布式系统天生有两大难题：网络不可靠和节点会挂掉。分布式一致性协议就是为了解决多个节点之间如何达成数据共识的问题。试想一下，你往分布式数据库写条数据，如果一半节点成功一半失败，这数据算不算数？这时候就得靠一致性协议来主持公道了。

面试官最爱问这类问题，因为这是分布式系统的基石。下面这些协议的名字，建议直接刻进DNA里👇

核心思想：搞个“协调者”（Coordinator）当裁判，分两阶段操作：
1. 投票阶段：协调者问所有参与者：“能提交不？”（参与者锁定资源）
2. 提交阶段：如果都同意 → 通知提交；只要一个反对 → 全体回滚
致命缺点：
❌ 同步阻塞：所有节点在投票后卡住等通知
❌ 单点故障：协调者宕机全员僵死
面试话术：

“2PC像开全体会议，必须所有人到场签字。协调者就是会议主持人，一旦主持人掉线，整个会议就卡死了。”

针对2PC的优化方案，新增 预提交阶段：
1. CanCommit：协调者试探节点状态（不锁资源）
2. PreCommit：参与者预提交并锁定资源
3. DoCommit：最终提交
进步意义：
✅ 减少阻塞：PreCommit阶段失败可及时中止
✅ 引入超时机制：节点超时自动提交（降低僵死概率）
面试坑点：

面试官可能会追问：“3PC能保证强一致性吗？”
答案是不能！网络分区时仍可能脑裂（某些节点提交，某些回滚）

分布式一致性协议鼻祖，被称为“最晦涩的算法”
核心角色：
- Proposer：提案发起者
- Acceptor：提案批准者
- Learner：学习最终值
两阶段流程：
1. Prepare阶段：Proposer争取提案权（带编号n）
2. Accept阶段：超半数Acceptor同意则提案生效
关键点：
🔑 提案编号全局递增 - 解决冲突
🔑 多数派（Quorum）原则 - N/2+1同意即生效
面试保命口诀：

“Paxos不是单一协议而是一族协议，常见变种有Multi-Paxos、Fast Paxos。它的价值在于证明了在异步系统中达成共识是可能的。”

设计目标：比Paxos更好懂！（Etcd、Consul都在用）
核心创新：
✅ 强Leader机制：所有写请求必须经过Leader
✅ 逻辑分片：把共识问题拆解成三个子问题：
1. Leader选举（心跳超时→ Candidate拉票）
2. 日志复制（Leader广播日志→ 多数Follower持久化）
3. 安全性保证（选举限制+提交规则）
面试必刷题：

“Raft如何避免脑裂？”
答案：新Leader必须包含旧Leader的所有已提交日志（通过选举时的Term和Index比较实现）

专为ZooKeeper设计的分布式一致性协议
工作流程：
1. 选举Leader：基于zxid（事务ID）最大原则
2. 数据同步：新Leader推送差异数据给Follower
3. 广播消息：两阶段提交（Leader提案→ Follower ACK→ Commit）
与Raft的区别：
| 特性 | ZAB | Raft | |----------------|-------------------------|--------------------| | 选举依据 | 最大zxid（事务ID） | 最大Term+Log Index | | 提交时机 | 所有Follower写入后提交 | 多数派写入即提交 | | 设计目标 | 高吞吐顺序一致性 | 强领导一致性 |

协议对比要张口就来：

“2PC像银行柜台转账——严谨但慢；Raft像小组长收作业——高效但依赖组长”
场景题高频考法：

问：“如果Redis集群用Raft做选举，某个节点网络延迟会怎样？”
答：“该节点可能因收不到心跳发起竞选，但由于Term低会被拒绝，最终集群仍以Leader为主”
死亡连环问破解：

面试官：“Paxos和Raft谁更好？”
参考答：“没有绝对好坏。Paxos更灵活适合多写场景，Raft易实现适合强Leader系统，关键看业务场景是否允许短时不可用。”

💡 小福利时间：
如果你最近准备面试，强烈推荐用 《2025 Java面试宝典》（文首网盘自取）。如果想省点钱开面试鸭会员，可以走 面试鸭返利网 找我，返现25元（直接扫码加我微信返现👇）

📌 一句话总结面试要点：
分布式一致性协议的核心逻辑 = 多数派投票 + 全局有序 + 故障恢复，吃透这三点，面试横着走！

面试鸭文档更多