第三章 一致性协议深度解析：Paxos / Raft / Zab 原理、选举过程、日志复制、脑裂处理
分布式存储工程师面试中，一致性协议是必考题。面试官通过考察你对 Paxos、Raft、Zab 的理解深度，评估你对分布式系统核心问题的掌握程度。本章聚焦三者的原理、选举流程、日志复制机制及脑裂处理方案，帮你在面试中对比清晰、回答有力。
面试问答卡片
面试问题：请对比 Paxos、Raft、Zab 三种一致性协议的核心区别，并说明它们各自如何解决脑裂问题？
面试官考察点：
- 是否理解三者设计哲学与适用场景
- 对脑裂成因及 quorum 机制的理解深度
- 能否讲清角色划分（Leader / Proposer / Follower）
回答框架：分类对比（原理→选举→复制→脑裂）→ 各协议关键差异 → 具体脑裂处理实例。
示例回答：Paxos 采用多数派（Quorum）避免脑裂，但无固定 Leader；Raft 通过 Term 和 Leader 强主导，配合任期心跳与超时选举，节点仅接受现任 Leader 日志；Zab 使用 ZXID 全序广播，主节点挂后通过 epoch 保证唯一性，三者都依赖多数派投票解决脑裂。
可能追问：Raft 中 Leader 挂掉时日志不一致如何解决？Paxos 的 Multi-Paxos 如何优化？
面试问题：Raft 协议中 Leader 选举的具体流程是怎样的？什么情况下会触发新的选举？
面试官考察点：
- 对 Raft 选举中 Term、角色、超时机制的理解
- 能否说清选举限制（日志最新原则）
- 分布式环境下选举失败的处理策略
回答框架：角色状态机 → 候选者发动选举 → 投票规则 → 任期递增 → 日志匹配 → 选主成功。
示例回答：Follower 超时（150~300ms 随机）后转为 Candidate，自增 Term，向所有节点发 RequestVote RPC，收到多数票后升为 Leader；投票时节点优先选 Term 更大且日志更新的候选者。 Leader 宕机或分区恢复时会触发新选举。
可能追问：如果集群出现网络分区，Leader 在少数分区，日志如何合并？
面试问题：Zab（ZooKeeper Atomic Broadcast）协议如何保证日志复制过程中消息的全局有序性？
面试官考察点：
- 对 ZXID 设计与全序广播的理解
- Le 选举与 Leader 发布阶段的区别
- Zab 与 Raft 在日志提交上的差异
回答框架：ZXID 组成（Epoch + Counter）→ 两阶段广播 → 同步历史日志 → 全局递增。
示例回答：Zab 利用 ZXID（64位，高32位 epoch，低32位 counter）保证消息唯一序号。Leader 在 Prepare 阶段向 Follower 广播提案，Follower 确认后 Leader 提交并通知。新 Leader 选举后加载历史日志，确保没有消息乱序。相比 Raft，Zab 始终依赖 Leader 全序广播，不采用乱序优化。
可能追问：Zab 中如何处理“幽灵日志”？
项目案例模板
项目名称：金融级分布式日志存储系统（基于 Raft 的强一致性引擎）
业务背景：为内部风控、交易链路提供低延迟、强一致的分布式存储服务，要求 RTO < 5秒、RPO = 0。
规模指标：5节点集群（3副本）、日均写入量 2TB、单节点 IOPS 5000、平均写延迟 < 3ms。
技术栈：Go + Raft（etcd/raft 库）、RocksDB 持久化、gRPC 通信、Prometheus 监控。
核心难点：
- Leader 频繁切换时日志复制断流，引起写抖动
- 磁盘故障导致日志截断与数据恢复一致性
- 网络抖动引发虚假脑裂，多数派形成延迟
面试高频追问：
- 你们如何监控 Raft 的 Term 变化？Leader 切换时业务如何感知？
- 如果发生脑裂，你们模拟过哪些场景？如何验证恢复正确性？
- 为什么选 Raft 而不是 Paxos 或 Zab？
可迁移回答话术：“我们选择 Raft 主要基于其角色清晰、易于实现监控与运维；针对 Leader 切换抖动，我们在应用层引入了指数退避重试和连接池预建立；脑裂处理方面，我们通过 Quorum 多数派表决并叠加 Leader 自检心跳超时（默认 2x election timeout）来区分临时网络抖动与真脑裂，同时记录所有 Term 变化的审计日志用于事后分析。”