3.3 选举过程

// 简化的 RequestVote 处理逻辑
func (rf *Raft) RequestVote(args *RequestVoteArgs, reply *RequestVoteReply) {
    rf.mu.Lock()
    defer rf.mu.Unlock()
    
    // 1. 对方 Term 比我小，拒绝
    if args.Term < rf.currentTerm {
        reply.Term = rf.currentTerm
        reply.VoteGranted = false
        return
    }
    
    // 2. 对方 Term 比我大，更新我的 Term 并退位
    if args.Term > rf.currentTerm {
        rf.currentTerm = args.Term
        rf.votedFor = -1
        rf.state = Follower
    }
    
    // 3. 检查是否已投过票（同 Term 内只能投一票）
    if rf.votedFor != -1 && rf.votedFor != args.CandidateId {
        reply.VoteGranted = false
        return
    }
    
    // 4. 检查候选者日志是否"至少和我一样新"
    lastLogIndex := len(rf.log) - 1
    lastLogTerm := rf.log[lastLogIndex].Term
    if args.LastLogTerm > lastLogTerm || 
       (args.LastLogTerm == lastLogTerm && args.LastLogIndex >= lastLogIndex) {
        rf.votedFor = args.CandidateId
        reply.VoteGranted = true
        rf.resetElectionTimer()  // 重置选举超时
    }
}

3.4 随机化超时避免选票分裂

如果多个 Follower 同时超时转为 Candidate，可能各自获得一部分选票而无人过半——即选票分裂（Split Vote）。Raft 的解法是让每个节点的选举超时随机化（例如在 [150, 300] ms 之间随机选取）。这样即使两个节点同时超时，它们超时的时刻也大概率错开，让一方先收集到多数票。

工程提示：生产实现中，超时应根据网络往返延迟（RTT）调整。跨 AZ 部署时 RTT 可能 5～20 ms，本地集群 0.1 ms 以内，超时应至少是 RTT 的 10～30 倍以避免误判。etcd 默认 election-timeout=1000ms。

四、日志复制：从客户端请求到提交

4.1 复制流程

1. 客户端向 Leader 发起写请求，Leader 把命令追加到本地日志（未提交状态）。
2. Leader 在下一个心跳周期把新日志通过 AppendEntries RPC 发给所有 Follower。
3. Follower 持久化日志并响应 Leader。
4. Leader 收到多数派确认后，将该日志标记为"已提交"。
5. Leader 提交日志到状态机，将结果返回客户端。
6. 下次心跳通知 Follower 哪些日志已经提交。

4.2 日志匹配特性（Log Matching Property）

Raft 维护一个关键的不变量：如果两个日志在相同索引和 Term 上有一条日志，则这两个日志在该索引之前的所有条目都完全相同。这条性质是安全性的基石，由以下两个机制保证：

• AppendEntries 一致性检查：Leader 在发送新日志时同时带上 prevLogIndex 和 prevLogTerm。Follower 检查自己在该索引处是否有匹配的日志，不匹配则拒绝。Leader 收到拒绝后会递减 nextIndex 重试，直到找到一个双方一致的位置。
• 日志追加规则：新的日志条目总是覆盖冲突后的所有条目。

4.3 提交规则——不能提交前任 Term 的日志

Raft 有一条反直觉的规则：Leader 不能通过计数副本数直接提交前任 Term 的日志条目。原因如下：

Term 2:  Leader=A 写入日志 index=2, term=2
Term 3:  A 宕机，B 成为新 Leader，写入 index=2, term=3
Term 4:  B 宕机，A 恢复成为新 Leader（Term 4）
         此时 A 的日志：[index=1,term=1], [index=2,term=2]
         B 的日志：[index=1,term=1], [index=2,term=3]
         A 继续复制——但 A 的 index=2 因为网络原因尚未复制到多数派

假设 A 的 index=2(term=2) 后来被复制到多数派，A 将其提交——但此时可能有新 Leader 已经在 index=2 处写入了不同的条目并提交，导致已提交的日志被覆盖，违反安全性。

正确做法：新 Leader 必须提交一条当前 Term 的日志（通常是 no-op 空条目），通过它的提交间接提交之前的所有日志。

五、安全性：选举限制与状态机安全

5.1 选举限制

Raft 保证任何 Term 的 Leader 都包含之前所有 Term 已提交的日志条目。因此选举限制为：候选者的日志必须至少和投票者的日志一样新。

"一样新"的比较规则：比较最后一条日志的 Term，Term 大的更新；Term 相同则索引大的更新。

5.2 Leader 完整性特性

如果一个日志条目在某个 Term 被提交，那么该条目必然存在于所有更高 Term 的 Leader 中。这条特性由选举限制保证：任何更高 Term 的 Leader 必须在选举时获得多数派投票，而已提交的条目也在多数派中的至少一个节点上，那个节点只会把票投给日志至少和它一样新的候选者。

5.3 状态机安全：提交后必须一致

核心保证：如果某个节点已将某个日志条目应用到其状态机，则没有其他节点会在同一索引处应用不同的条目。因为提交的条目存在于多数派中，而任何后续 Leader 也必须持有该条目，后续在该索引处的任何写入都必须覆盖为相同内容。

六、成员变更：运行时扩缩容

6.1 直接切换的问题

如果直接转换配置（如 3 节点→5 节点），转换期间可能出现双 Leader：旧配置的多数派和新配置的多数派可能不重叠，各自独立选出 Leader。

6.2 联合共识（Joint Consensus）

Raft 论文推荐使用两阶段成员变更：

1. 过渡阶段：进入联合配置 C_old,new，所有决策需要旧配置和新配置的两个多数派同时同意——这样旧多数派和新多数派必然有交集，保证不会出现双 Leader。
2. 提交新配置：C_old,new 提交后，切换到 C_new 并结束联合阶段。

时间线示例（5 节点扩到 7 节点）：
  [A B C D E] --> [A B C D E] + [F G] 进入 cold,new 状态
  决策需要:
    - 旧多数: 3/5 同意（如 A B C）
    - 新多数: 4/7 同意（如 A B C F）
  交集保证: 一个多数派是另一个的子集或相交
  --> 提交 cold,new 后切换到 Cnew=[A B C D E F G]

6.3 实践中的单步变更（etcd 做法）

etcd 的 Raft 实现做了简化——每次只变更一个节点。单步变更的安全性证明：在变更前后，新旧两个多数派必然有交集（因为 n 和 n+1 的多数派各需要 n/2+1 和 (n+1)/2+1，交集至少一个节点）。

七、性能优化与生产实践

7.1 批量与流水线（Batching & Pipelining）

• 日志批量提交：多个客户端请求打包成一个 AppendEntries，减少 RPC 次数。
• 日志复制流水线：Leader 不等上一个 AppendEntries 的响应就发送下一个，提高网络利用率。
• etcd 的实现：Leader 维护每个 Follower 的 nextIndex/matchIndex，每个 Follower 有一个 goroutine 异步发送日志，支持并发复制。

7.2 只读请求的优化

简单实现会把只读请求也走日志复制（确保线性一致性），但这代价太高。两种优化策略：

• Lease Read（租约读）：Leader 在心跳期间收集多数派确认自己的 Leader 身份，在租约期内（通常为一个选举超时周期）允许不经过 Raft 日志直接读状态机。这是 etcd v3 的默认方式。
• Read Index：Leader 收到读请求时先广播一次心跳确认自己的 Leader 身份，记录下当前的 commitIndex，等待状态机应用到该 index 之后返回读结果。适用于 Leader 身份需要动态确认的场景。
• Follower Read：Follower 向 Leader 查询最新的 commitIndex，等待本地状态机应用后返回结果，将读压力分散到 Follower。

7.3 快照与日志压缩

长时间运行的节点日志会无限增长。Raft 使用快照（Snapshot）机制：Leader（或滞后的 Follower）拍一个状态机的一致性快照，丢弃已包含在快照中的日志条目。

关键流程：

1. Leader 通过 InstallSnapshot RPC 把快照发送给远远落后的 Follower。
2. Follower 收到快照后，用它替换状态机，丢弃快照覆盖的所有日志。
3. 快照中记录 lastIncludedIndex 和 lastIncludedTerm，后续 AppendEntries 的一致性检查从快照之后继续。

7.4 线性一致性与读操作

在 Raft 实践中，默认的"读状态机当前值"并不能保证线性一致性（Linearizability）：如果 Leader 的身份不确定（可能刚刚发生分区但 Leader 自己不知道），读到的可能是过期的数据。保证线性一致性需要：

• 所有写必须通过 Raft 提交。
• 读必须使用 Lease Read 或 Read Index 确认 Leader 身份。
• 或者采用 Read Your Writes 语义：客户端在读请求中携带从上次写操作获得的 readIndex，等状态机应用到该 index 后才返回。

八、故障排查经验

九、与其他共识算法对比

十、总结与展望

Raft 之所以成为工业界共识算法的"默认选择"，不仅因为它清晰的分治思想——Leader 选举、日志复制、成员变更三大模块的可组合性——更因为它在安全性证明和生产可运维性之间取得了恰到好处的平衡。

核心要点回顾：

• Term 是逻辑时钟：过期节点检测到 Term 增长后自动退位，无需外部信号。
• 日志匹配特性：通过 prevLogIndex/prevLogTerm 一致性检查，保证日志索引处的值在集群中一致。
• 不提交前任 Term 日志：新 Leader no-op 提交是必须的，否则可能丢失已提交条目。
• 联合共识：两阶段成员变更保证新旧配置的多数派有交集。
• Lease Read / Read Index：避免只读请求走日志复制的开销。
• 快照压缩：防止日志无限增长，加速落后节点的追赶。

未来演进方向：Pre-Vote 机制（防止网络隔离的节点不断发起无效选举拉高 Term）、Leader Lease（更精确的 Lease Read 时钟边界）、Joint Consensus 的单节点优化（Raft 作者 Diego Ongaro 在博士论文中已提出）以及面向异构硬件的并行日志追加。对于真正实现"生产级"共识，理解原理只是第一步，真正的功力在超时参数调优、网络分区演练和性能 profiling 之中。