Shirone

为什么需要：主从复制的天花板#

前面的文章里，MySQL 高可用靠 binlog 复制 + 外部选主，Redis 高可用靠主从 + 哨兵。它们的共同点是：复制解决”数据有几份”，但”谁说了算”始终悬而未决。

复制提供副本，共识提供”唯一的真相”。只要系统里存在”多个副本 + 需要自动决策”，就迟早要面对共识问题：

• etcd / Consul / ZooKeeper 存的是”集群的元数据”，本身就必须强一致，否则 K8s 的调度、租约、分布式锁全部失效；
• Redis Sentinel 要在多个哨兵之间决定”谁是新主”，本质是一次配置共识；
• MySQL MGR 要通过组通信决定”这个事务是否被接受且顺序固定”，本质是一次日志共识。

Paxos：共识的理论起点#

Paxos（Lamport, 1998）是第一个被严格证明正确的共识算法，围绕三个角色：

核心是两阶段：

1. Prepare 阶段：Proposer 用编号 n 询问多数派 Acceptor：“是否已接受过编号小于 n 的提案？“Acceptor 承诺不再接受编号小于 n 的提案，并返回它已接受的最高编号提案的值。
2. Accept 阶段：Proposer 若发现有人已接受过某值，就必须沿用那个值（这是安全性的关键）；否则可用自己的值。向多数派发送 Accept 请求，多数派接受即提案被选定。

于是得到共识的两个基本事实：

• 多数派交集：任意两个多数派必然有交集，因此”已被选定的值”一定会被后续 Proposer 看到并沿用，不会出现两个不同的值同时被选定；
• 半数才可推进：少于多数派的任何集合都无法独立做出决定，这是”防脑裂”的数学基础。

Paxos 的问题不在正确性，而在可理解性与工程化：

• 原始 Paxos 只描述了”选定一个值”，而工程需要的是连续决策的日志（Multi-Paxos），其中的 Leader 选举、日志空洞填补、成员变更都要额外设计；
• 论文晦涩，实现差异极大，几乎没有两个团队的 Paxos 实现长得一样；
• 缺少”领导者”这一显式角色时性能很差（每写一条日志都要两轮往返）。

Raft：为可理解性而生的共识#

Raft（Ongaro & Ousterhout, 2014）的目标很直白：在功能与性能上与 Multi-Paxos 等价，但把问题拆成几个可独立理解、可独立实现的部分。

Raft is a consensus algorithm that is designed to be easy to understand. It’s equivalent to Paxos in fault-tolerance and performance.

相比 Paxos，Raft 做的关键工程化选择：

角色与任期#

每个节点在任意时刻处于三种角色之一：

任期（Term） 是单调递增的整数，充当逻辑时钟：

• 每次选举开始，任期 +1；
• 任期号承载在每一次 RPC 里；任何节点收到比自己任期更大的请求，立即更新自己的任期并转为 Follower；
• 收到比自己任期更小的请求，直接拒绝（并回传自己的任期，让对方知难而退）。

由于”同一任期最多一个 Leader”，所有一致性判断都可以归结为”任期号大小比较”，不需要假设时钟同步。

子问题一：Leader Election#

1. 集群启动或 Leader 失联时，Follower 在 election timeout（通常 150~300ms） 内没收到心跳，就转为 Candidate；
2. Candidate 任期 +1，投自己一票，向所有节点并发发送 RequestVote；
3. 节点在一个任期内只投一票（先到先得），并在”候选人的日志至少和自己一样新”时才投票；
4. 拿到多数派票的 Candidate 成为 Leader，立即发送心跳宣告权威；
5. 如果出现平票（常见于多个节点同时超时），本轮无人当选，各自等待随机化的选举超时后重试——随机化是打破僵局的关键，把活锁概率压到可忽略。

1
RequestVote(term, candidateId, lastLogIndex, lastLogTerm) → (term, voteGranted)
2
AppendEntries(term, leaderId, prevLogIndex, prevLogTerm, entries[], leaderCommit)
3
    → (term, success, conflictIndex, conflictTerm)

Raft 只有这两个 RPC。AppendEntries 同时承担日志复制和心跳两个职责（entries 为空时就是心跳）。

子问题二：Log Replication#

一次完整的写入：

1. 客户端把命令发给 Leader；
2. Leader 把命令追加为本地日志条目，记录 (index, term, command)；
3. Leader 向所有 Follower 发 AppendEntries；
4. 当该条目被复制到多数节点（含 Leader 自己）时，Leader 把它提交（commit）并应用到状态机，然后把结果返回客户端；
5. 后续的心跳会携带 leaderCommit，Follower 据此知道哪些条目已提交，并按顺序应用到自己的状态机。

两条关键不变式：

• Log Matching Property：如果两个日志在相同 index 上的条目 term 相同，则它们及之前的所有条目完全相同；
• 状态机安全：Leader 只能提交”自己任期内”的条目；跨任期的旧条目要等本任期的新条目提交后，才被间接提交（这是 Raft 论文中容易被忽略、但实现时极易出错的一条规则）。

日志不一致的修复：Follower 拒绝不一致的 AppendEntries 后，Leader 用 nextIndex 逐步回退（论文原版是每次减一，实现上通常用 conflictIndex 一次跳过大段冲突日志），直到找到匹配点，再从这里开始覆盖 Follower 上所有冲突条目——Follower 上未提交的条目以 Leader 为准。

子问题三：Safety#

Raft 用五条规则保证”已提交的永不丢失、状态机执行顺序一致”：

持久化要求：currentTerm、votedFor、日志条目在响应 RPC 前必须落盘（fsync）。只把 commitIndex、lastApplied 放内存是可以的（重启后从 Leader 重建）。忘了持久化 votedFor，就会在重启后投出两票，直接破坏选举安全性——这是自研 Raft 最常见的翻车点。

子问题四：成员变更#

集群运维中增删节点不能靠”停集群改配置”，否则配置不一致的瞬间可能出现两个多数派。Raft 的解法是联合共识（Joint Consensus）：先进入 C_old,new 联合配置（任何决定需同时在两套配置中取得多数），再切到 C_new。工程实现里更常用的是单节点变更（One-at-a-time）：一次只加或减一个节点，此时新旧配置的多数派必然有交集，因而不需要联合配置的复杂度。

etcd 的成员变更（etcdctl member add/remove）就是走这条路径，因此它要求一次只变一个成员，且变更期间集群不应处于故障状态。

共识的代价#