Raft 共识算法从零实现：Leader 选举、日志复制与共识安全的完整工程实践

引言：为什么分布式共识如此重要

在分布式系统中，多个节点就某个值达成一致（Consensus）是最核心的难题之一。从 etcd 的服务发现、TiKV 的分布式事务、Consul 的 Leader 选举，到 Kafka 的 Controller 选举、Ceph 的 OSD Map 同步——共识算法是现代分布式基础设施的基石。

Raft 算法由 Diego Ongaro 和 John Ousterhout 于 2014 年在论文《In Search of an Understandable Consensus Algorithm》中提出，其核心设计目标是可理解性（Understandability）——相比 Paxos 的难以理解，Raft 通过分解问题（Leader 选举、日志复制、安全性）和减少状态空间，使得工程实现变得可行且可靠。

Raft vs Paxos vs Zab

Raft 核心概念模型

三种角色状态与转换

Raft 将节点抽象为三种严格互斥的状态：Follower、Candidate 和 Leader。状态之间的转换由事件触发：Follower 超时未收到 Leader 心跳则转为 Candidate；Candidate 获得多数票后成为 Leader；任何节点发现更高的 Term 立即降级为 Follower。

Term（任期号）的全局有序性

Term 是 Raft 逻辑时钟的核心。每个 Term 最多产生一个 Leader，全局严格递增。节点通信时携带当前 Term，发现更大 Term 则立即降级。

深度解析 Leader 选举机制

随机化超时与冲突避免

Raft 选举稳定性的关键在于随机化选举超时。如果所有 Follower 使用相同超时时间，分割投票将无限持续。通过随机化（通常 150ms-330ms），第一个超时的 Candidate 极大概率能先发出请求，从而赢得选举。

选举完整流程

func (rf *Raft) startElection() {
    rf.mu.Lock()
    rf.state = Candidate
    rf.currentTerm++           // Term 自增
    rf.votedFor = rf.id        // 给自己投票
    rf.resetElectionTimeout()
    term := rf.currentTerm
    lastLogIndex := len(rf.log) - 1
    lastLogTerm := rf.log[lastLogIndex].Term
    rf.mu.Unlock()
    votes := 1
    for _, peer := range rf.peers {
        if peer == nil { continue }
        go func(p *rpc.Client) {
            args := RequestVoteArgs{
                Term: term, CandidateID: rf.id,
                LastLogIndex: lastLogIndex, LastLogTerm: lastLogTerm,
            }
            var reply RequestVoteReply
            if p.Call("Raft.RequestVote", &args, &reply) {
                rf.mu.Lock()
                defer rf.mu.Unlock()
                if reply.Term > rf.currentTerm {
                    rf.becomeFollower(reply.Term); return
                }
                if rf.state != Candidate || rf.currentTerm != term { return }
                if reply.VoteGranted {
                    votes++
                    if votes > len(rf.peers)/2 { rf.becomeLeader() }
                }
            }
        }(peer)
    }
}

RequestVote 的日志完整性检查

Follower 投票时不仅检查 Term，还要检查 Candidate 的日志至少比自己新（Raft 安全性的第一道防线）：比较最后一个日志条目的 Term，Term 大的更新；Term 相同则比较 Index，Index 大的更新。

深度解析日志复制机制

AppendEntries RPC 的幂等性与一致性检查

日志复制是 Raft 最常用的操作。Leader 将客户端命令打包为 LogEntry，通过 AppendEntries RPC 并行发给所有 Follower，当多数派确认后即提交。关键设计：

• PrevLogIndex/PrevLogTerm 一致性检查，保证日志连续性
• 冲突截断机制：发现 Term/Index 不匹配时，截断冲突位置并写入新条目
• 幂等性：相同 Term 相同 Index 的条目视为已写入

Leader 端的提交推进

Leader 维护每个 Follower 的 nextIndex 和 matchIndex。当某条日志被多数派确认时，更新 commitIndex。核心安全规则：Leader 只能提交当前 Term 的日志条目，防止幽灵日志问题。

安全性约束与 Raft 不变式

选举限制

新 Leader 必须获得多数派投票，而已提交的日志也至少在多数派中的一个节点上存在。这两个多数派必然有交集，因此新 Leader 必然包含所有已提交的日志。

Leader 只追加原则

Raft Leader 永远不会覆盖或删除自己的日志，只追加新条目。

提交规则

Leader 只能提交当前 Term 的日志条目。这是防止幽灵日志问题的精髓：旧 Term 的日志只有通过提交当前 Term 的日志来间接提交。

持久化与崩溃恢复

Raft 要求节点在响应 RPC 之前必须将关键状态持久化：currentTerm（防过期选举）、votedFor（防重复投票）、log（保证已提交日志不丢失，用于日志匹配检查）。

日志压缩与快照机制

无限增长的日志导致磁盘空间耗尽和重启恢复过慢。解决方案：节点将已提交日志应用到状态机的结果持久化为快照，然后丢弃这些日志。严重滞后的 Follower 通过 InstallSnapshot RPC 接收快照。

集群成员变更

Raft 通过 Joint Consensus（联合共识）实现安全的两阶段成员切换，避免脑裂。实践中常采用单节点变更策略：每次只添加或移出一个节点，数学上等价于 Joint Consensus 的安全性保证。

线性一致读

三种实现方案：ReadIndex（心跳多数派确认后读，1 次 RTT）、LeaseRead（租约期内本地读，0 RTT）、LogRead（AppendEntries 确认后读，1 次 RTT）。etcd 默认使用 LeaseRead 以获得最佳读性能。

生产级性能优化

• 批处理：积累多条日志后一次性发送，减少系统调用和网络开销
• 流水线：不等上一个 AppendEntries 响应就发送下一个，充分利用带宽
• PreVote：预选举协议防止网络分区恢复时的 Term 飙高
• 并行 Apply：Commit 与 Apply 解耦到独立 goroutine
• Learner 节点：不参与投票的只读副本，用于读扩展和新节点追赶

主流 Raft 实现对比与调优

关键调优参数

• ElectionTimeout: 150ms-300ms（过短导致频繁切换，过长增加故障恢复时间）
• HeartbeatTick: 约 ElectionTimeout 的 1/10
• MaxSizePerMsg: ~1MB
• SnapshotInterval: 两次快照间最小日志条数
• SnapshotChunkSize: 1-4MB

调试与排查

Leader 频繁切换检查 Term 增量日志和 ElectionTimeout 设置。CommitIndex 停滞排查磁盘 IO，引入 Learner 或替换慢节点。

总结

Raft 通过将共识问题分解为 Leader 选举、日志复制和安全性三个子问题，使得工程实现比 Paxos 更可靠可维护。经过十年生产验证，Raft 已成为分布式系统最主流的一致性协议。掌握 Raft 是通往高可用分布式系统工程师的必经之路。