一致性协议 — 分布式系统

1. Raft 协议的核心机制？（必考）

角色：Leader（处理写入）、Follower（被动复制）、Candidate（选举中）。任期 term 递增。

三大机制：

Leader 选举：
- Follower 超时未收到心跳（election timeout，随机 150~300ms）→ 变 Candidate 自增 term 投票
- 获得大多数（过半）选票成为 Leader；平票则随机超时再选
- 过半机制保证：一个任期内最多一个 Leader（每张票只投一次）
日志复制：
- 客户端写请求 → Leader 追加日志 → 复制到 Follower → 过半确认后提交并返回成功
- 日志带任期和索引，Follower 检查连续性（prevLogIndex/prevLogTerm）——保证日志一致
安全性：
- 选举限制：Candidate 的日志必须"足够新"（最后一条日志的任期/索引）才有资格当选
- 提交限制：Leader 不能提交旧任期的日志（只有当前任期的日志过半才提交，顺带提交之前未提交的）

ZAB（ZooKeeper Atomic Broadcast）：ZooKeeper 的原子广播协议，三个角色：Leader / Follower / Observer。两大阶段：

与 Raft 对比：

相同：Leader 制、过半提交、任期/纪元机制（epoch 对应 term）
不同：Raft 用"随机超时选举 + 日志连续性校验"；ZAB 用"zxid 大小比较"（zxid = epoch + 自增序号，天然有序）；Raft 更易理解实现，ZAB 专为 ZooKeeper 设计

Paxos：分布式共识的开山理论（Lamport 提出）。核心思想：prepare（承诺）→ accept（提案）→ 多数派通过。Raft 是 Paxos 的简化工程版（多 Paxos）。理解"多数派 + 两阶段"即可，不必背细节（面试考 Raft 更多）
Gossip（流言协议）：节点间随机互传信息，最终一致（AP 风格）。特点：去中心、可扩展（O(log n) 收敛）、健壮。应用：Redis Cluster 节点状态同步、Cassandra 副本同步、区块链 P2P

对比：Raft/Paxos 是强一致（CP），Gossip 是最终一致（AP）——按场景选
Redis Cluster 的心跳（gossip）互传节点状态，cluster-node-timeout 默认 15000 ms；超时先标记 PFAIL，再由多数 master 确认后升级为 FAIL

Raft 的核心机制（背 3 点）？——Leader 选举（随机超时 + 过半选票）、日志复制（过半确认才提交）、安全性（选举限制 + 提交限制）。
为什么过半（多数派）是关键？——任何两个多数派必有交集 → 不会出现两个 Leader 同时提交不同数据；容错：3 节点容忍 1 宕机、5 节点容忍 2。
Raft 和 ZAB 的区别？——同：Leader 制 + 过半提交 + 任期/纪元；异：Raft 随机超时选举 + 日志连续性校验，ZAB 用 zxid 排序（epoch+序号）。Raft 更易懂，现代新系统（ETCD/KRaft）都用 Raft。
Gossip 是什么？和 Raft 的区别？——Gossip：节点随机互传信息最终一致（AP，Redis Cluster 状态同步）；Raft：强一致（CP）。按一致性要求选。
Paxos 和 Raft 的关系？——Paxos 是共识理论鼻祖（两阶段多数派），难理解难实现；Raft 是其工程化简化版，面试考 Raft 即可。

术语	大白话解释
Raft	分布式共识协议：多节点就"谁当 Leader、日志怎么提交"达成一致（过半机制）。ETCD、Kafka KRaft 用它。
Leader / Follower / Candidate	Raft 三角色：Leader 处理写请求；Follower 被动复制；Candidate 参与选举。
任期（Term）/ 过半	任期 = 每次选举的"届"；过半 = 多数派确认（N/2+1），保证唯一 Leader 和数据不冲突。
ZAB	ZooKeeper 的原子广播协议：zxid 有序 + 过半提交，保证 ZooKeeper 的强一致。
zxid	ZooKeeper 的事务 ID（纪元+序号），全局有序——日志复制的顺序依据。
Paxos	共识算法鼻祖（Lamport）：prepare/accept 两阶段多数派。理论价值 > 工程价值。
Gossip（流言协议）	节点间随机互传状态，最终一致、去中心、可扩展——Redis Cluster 用它。
共识（Consensus）	多节点对"同一个值"达成一致的过程——分布式系统一致性的核心机制。