2. Raft 的三个角色？
Leader：唯一对外提供写服务，负责日志复制和心跳。
Follower：被动接收 Leader 的日志和心跳。
Candidate：Follower 超时后发起选举，争取成为 Leader。
3. Raft 的核心机制？
Leader 选举
Follower 超时没收到心跳 → 变为 Candidate → 拉票 → 超过半数支持 → 成为 Leader。
用 任期 term 区分不同 Leader。
日志复制
Leader 接收客户端请求，写入日志并复制给 Follower。
超过半数节点写成功 → 日志提交。
Leader 通知状态机执行该日志（保证线性一致性）。
安全性
新 Leader 必须有最新日志才能赢得选举（避免数据回退）。
只有 Leader 提交的日志才能算已提交。
“超时”的含义
在 Raft 里，Follower 的“超时”指的是在选举超时时间内没有收到 Leader 的心跳，而不是节点本身宕机。
超时后它会升级成 Candidate，发起投票选举，有可能成为新的 Leader。
如果节点真的宕机了，它根本不能发起选举；这时其他节点会超时并完成选举。
这样就保证了只有活着的节点才能当 Leader，不会出现宕机节点被选举成功的情况。
4. Raft 怎么解决脑裂？
脑裂：多个节点都认为自己是 Leader。
解决办法：
任期 term 唯一递增，Follower 只投票给 term 最大、日志最新的节点。
日志提交必须多数派确认。即使出现多个 Leader，也只有一个能赢得多数派。
5. Raft 为什么比 Paxos 更易懂？
Paxos 思想精妙但难实现（两阶段提交 + 多个角色）。
Raft 把一致性问题拆成了三个子问题：Leader 选举、日志复制、安全性。
每个部分逻辑独立，易于实现。
论文里还提供了伪代码和可视化解释。
6. Raft 和 ZAB（ZooKeeper 的一致性协议）的区别？
Raft：选举 + 日志复制，Leader 负责多数派写入确认。
ZAB：类似两阶段提交，Leader 广播提议（proposal），Follower 应答，Leader 收到多数确认后再提交。
相同点：都依赖 Leader，保证强一致性。
不同点：Raft 更强调日志连续性和可理解性，ZAB 偏重于事务提交模型。
7. Raft 的应用场景？
配置中心：Etcd（K8s 用来存储配置和状态）。
服务发现：Consul。
分布式数据库：TiKV（TiDB 的存储引擎）、CockroachDB。
日志复制 / KV 存储：应用在高一致性系统中。
评论