分布式共识算法Raft深度解析：从Leader选举到日志复制的工程实践

引言

在分布式系统中，共识（Consensus）是最核心的问题之一——如何让多个节点就某个值达成一致，即使部分节点发生故障。Raft算法作为Paxos的"替代品"，以其更易理解的特性被广泛应用于etcd、TiKV、CockroachDB等系统中。本文将深入剖析Raft的核心机制，并探讨工程实现中的关键优化。

1. Raft基础架构

1.1 节点状态机

Raft将节点分为三种状态：Leader（领导者）、Follower（跟随者）和Candidate（候选人）。整个集群在任何时刻只有一个Leader，所有写请求必须经过Leader处理，这简化了一致性问题的复杂度。

Follower → (选举超时) → Candidate → (获得多数票) → Leader
Leader → (发现更高任期) → Follower
Candidate → (发现更高任期或新Leader) → Follower

1.2 任期（Term）机制

Raft将时间划分为任意长度的任期，每个任期从一次选举开始。任期编号（Term ID）是单调递增的，节点在通信时会交换任期号——如果发现自己任期落后，就更新到最新值。这提供了一种逻辑时钟，用于检测过期信息。

2. Leader选举详解

2.1 选举触发与投票

当Follower在选举超时时间内（通常150-300ms随机化）未收到Leader的心跳，就转变为Candidate并发起选举：

1. 增加当前Term，投票给自己
2. 重置选举计时器
3. 向所有其他节点发送RequestVote RPC
4. 如果获得多数票（⌈n/2⌉），成为Leader
5. 如果收到新Leader的心跳，退化为Follower
6. 如果选举超时，开始新一轮选举

2.2 随机化超时防止分裂

Raft的关键创新在于随机化选举超时时间。当集群分裂或Leader失效时，多个节点几乎同时超时成为Candidate，导致票数分散。通过将超时时间设为150-330ms的随机范围，大大降低了"分裂投票"的概率。

3. 日志复制机制

3.1 日志条目结构

每个日志条目包含：Term（创建该条目的任期）、Index（在日志中的位置）、Command（状态机命令）。Raft的核心不变性是"日志匹配特性"：如果两个日志条目有相同的Index和Term，则它们存储相同的命令，且之前的所有条目也相同。

3.2 复制流程

Leader接收客户端命令后：

1. 追加到本地日志（未提交状态）
2. 并行向所有Follower发送AppendEntries RPC
3. 等待多数节点确认
4. 提交该条目（应用到状态机）
5. 返回客户端成功响应
6. 在后续RPC中通知Follower提交进度

4. Multi-Raft：分片级共识

4.1 为什么需要Multi-Raft

单Raft组只能利用单台机器的处理能力。Multi-Raft将数据分片（Shard），每个分片由一个独立的Raft组管理，从而将负载分散到整个集群。

4.2 TiKV的Multi-Raft实现

TiKV使用Region作为基本调度单元（默认96MB），每个Region对应一个Raft组。关键设计包括：

• 心跳合并：Store级别心跳代替Region级别心跳，减少网络开销
• 分离传输层：不同Store间建立TCP连接，所有Raft消息复用连接
• 乱序调度：允许Follower乱序接收日志条目，提高吞吐量
• Lease Read：基于时间戳的一致性读取，避免ReadIndex的磁盘IO

5. 线性一致性与读优化

5.1 ReadIndex协议

为了保证线性一致性读（Linearizable Read），Leader必须确认自己仍是Leader。ReadIndex的做法：

1. Leader记录当前commit index为read index
2. 向多数节点发送心跳确认领导权
3. 等待状态机应用到read index
4. 返回读取结果

5.2 Lease Read优化

通过在租约期内跳过心跳确认，Read Index进一步优化为Lease Read。Leader基于本地时钟判断租约有效性，减少一次RTT。但要求各节点时钟偏差小于租约时间的一半。

6. 成员变更与动态扩缩容

6.1 联合共识（Joint Consensus）

直接切换配置可能导致集群脑裂。Raft两阶段成员变更（Joint Consensus）通过中间状态保证安全：

1. 切换到联合配置C(old,new)，请求需同时获得old和new的多数确认
2. 切换到最终配置C(new)，此时系统不再依赖旧配置

6.2 单步变更（Single-Server Change）

每次只增减一个成员，保证新旧配置的多数集必然相交。虽然扩缩容速度慢，但实现更简单，etcd采用此方案。

7. 工程实践中的关键优化

7.1 日志压缩与快照

日志无限增长不可持续。Raft通过快照（Snapshot）解决：当日志达到阈值，Leader创建快照发送给落后的Follower。快照使用InstallSnapshot RPC传输，包含last included index、term和状态机数据。

7.2 Pre-Vote与Check Quorum

Pre-Vote防止网络分区节点回来后干扰集群：节点在正式发起选举前，先进行Pre-Vote试探，只有确认能获得多数支持才真正增加Term。Check Quorum则让Leader定期检查是否仍是多数派。

总结

Raft通过强Leader模型将共识问题分解为Leader选举、日志复制和安全性三个相对独立的子问题。Multi-Raft进一步将这种一致性扩展到大规模数据分片场景。理解Raft的工程优化（Lease Read、Pre-Vote、快照压缩）对于构建可靠的分布式系统至关重要。