Raft：一本账，靠多数派保持一字不差

它是干嘛的。 一群机器要对外像一台：一份真相，死掉少数派也不能乱、绝不能裂成两个真相。协调服务的内脏（etcd、Consul）、分布式数据库的元数据层、Kafka 内置的控制器（KRaft），干的都是这个工种。

核心洞察：复制的是账本，不是数据。 每台机器存同一本按顺序记命令的日志，各自从头重放同一本账得到状态——账一样，状态必然一样。Raft 的全部工作化简成一句：让全网维护同一本账。

角色与任期。 一个 Leader（唯一的写入口），余皆 Follower。时间被切成任期（term）：只增不减的代号，旧任期的消息一律不认，过期 Leader 由此自动退休。

选举。 Leader 靠心跳证明活着。Follower 超时没等到心跳，就把 term 加一、转 Candidate、先投自己再拉票，拿到多数票者当选。两个故意的细节：选举超时每台随机，免得所有人同时起立把票分光；投票只投给账本不比自己旧的竞选者——这一条保证新 Leader 手里必然带着全部已提交的账。

记账与提交。 写请求到 Leader：先追加进自己的账（未提交），再抄送各 Follower，多数派确认存好之后才标记为已提交、执行并回复客户端。多数派是两道安全栓：任意两个多数派必然相交，所以已提交的账必然出现在任何能选出下任 Leader 的人群里；而网络分区时，少数派那侧既选不出头、也凑不齐提交，只能停摆而不是分叉。愈合后，它残留的未提交烂账被正账直接覆盖。

成本。 集群用奇数台（3 台容忍死 1、5 台容忍死 2；4 台仍只容忍 1，纯浪费）；每次写要等多数派一个往返；Leader 是写瓶颈——Raft 只共识一本账，大系统按分片跑许多组（multi-raft）。

Raft 与 ZAB 的对比。 ZAB（ZooKeeper Atomic Broadcast，雅虎，约 2008）是 Raft 的表哥，驱动 ZooKeeper；Raft（斯坦福，2014）是后辈，明说为"可理解"而设计。骨架相同——Leader、纪元/任期、多数派、按序的日志复制。差别在：(1) 出身：ZAB 是为单个产品做的主备协议（原子广播），Raft 是为教学和复现做的通用共识算法。(2) 换届方式：ZAB 把换届办成一个显式仪式——单独的选举阶段，之后还有 discovery/sync 阶段，先确立新纪元、对齐各家历史，才开始广播新账；Raft 把这收进正常流程——投票时的账本审查保证新头带着已提交的前缀，AppendEntries 的一致性检查在恢复复制时顺手把各家日志掰齐。(3) 出没地点：ZAB 几乎只活在 ZooKeeper 里；Raft 遍地——etcd、Consul、TiKV、CockroachDB，以及 Kafka 用自家 Raft（KRaft）替掉了 ZooKeeper。(4) 两者同源：Multi-Paxos 是共同祖先。