一、Raft 核心概念
Raft 是一种基于领导者（Leader） 选举的共识算法，TiDB 基于 Raft 实现了数据的分布式一致性，核心角色定义如下：
- 主副本（Leader）：每个 Raft Group（对应 TiDB 的一个 Region）中唯一的主节点，负责接收客户端的读写请求、发起日志复制和管理集群状态，是整个 Group 的核心决策节点。
- 从副本（Follower）：被动接收 Leader 同步的日志，响应 Leader 的心跳和日志复制请求，不主动发起任何决策，仅在 Leader 故障时参与新 Leader 选举。
- 候选副本（Candidate）：当 Follower 长时间未收到 Leader 心跳（超过选举超时时间）时，会转换为 Candidate 角色，向集群内其他节点发起投票请求，争取成为新的 Leader。
Raft 共识算法的核心目标是保证分布式集群中数据的一致性，核心承载两个关键功能：
a. Raft 日志复制
实现数据在集群节点间的可靠同步，是保证数据一致性的核心手段；
b. Leader 选举
保证集群在 Leader 故障时能快速选出新的 Leader，维持集群的可用性，避免单点故障。
二、Raft 日志复制机制
1. 日志本质与特性
TiDB 中的 Raft 日志并非数据库的 WAL（Write-Ahead Log，预写日志），而是一套独立的、面向分布式共识的逻辑日志（类似 MySQL 的 binlog 逻辑日志，而非 InnoDB 的 WAL 物理日志）。其核心作用是将数据库的操作（如增删改）封装为标准化日志条目，通过共识算法同步到集群所有节点，最终保证所有节点的数据状态一致，实现数据强一致性。
2. 完整复制流程（五阶段）
Raft 日志复制是一个严格的有序流程，从客户端请求到数据最终落地数据库，分为以下五个核心阶段：
| 阶段 | 核心动作 | 详细说明 | 关键保障 |
|---|---|---|---|
| Propose（提议） | 操作转换为 Raft 日志 | 客户端的写请求（如 put(key=1, name='sheldon')）被 Leader 接收后，首先被转换为标准化的 Raft 日志条目。日志条目格式包含：- 唯一标识：RegionID_日志序列号（如 Region 1 的第一条日志为 1_1）；- 日志内容：封装操作类型和具体数据（如 log{PUT key=1, name='sheldon'}）。 |
保证操作被标准化，可跨节点识别和同步 |
| Append（追加） | 日志本地持久化 | Leader 将 Propose 阶段生成的日志条目写入本地的 Raft Log 存储（通常为磁盘），完成本地持久化。⚠️ 关键：Append 完成后，即使 Leader 节点宕机，该日志也不会丢失，是数据不丢的第一道保障。 | 日志本地落地，避免内存数据丢失 |
| Replicate（复制） | 日志同步至 Follower | Leader 向集群内所有 Follower 节点发送日志复制请求，Follower 接收后先将日志写入本地 Raft Log（完成自身的 Append 操作），再向 Leader 回复 “复制成功” 响应。 | 日志扩散至集群，为共识确认做准备 |
| Committed（提交） | 达成集群共识 | Leader 统计收到 “复制成功” 响应的节点数量，当响应节点数超过集群半数（如 3 节点集群需 ≥2 个响应，5 节点集群需 ≥3 个响应）时，判定该日志达成集群共识，标记为 “Committed”。⚠️ 注意：此 “提交” 是 Raft 算法层面的共识确认，并非数据库事务的 COMMIT 操作。 |
保证日志在集群中具备一致性，即使 Leader 切换也不影响数据完整性 |
| Apply（应用） | 日志落地数据库 | Leader 将 “Committed” 状态的日志解析为具体数据库操作，执行并写入 TiKV（TiDB 的存储层）；同时 Leader 通知所有 Follower 执行该日志的 Apply 操作，最终所有节点的数据库状态保持一致。 | 日志转换为实际数据，完成最终落地 |
补充说明
- Raft 日志的有序性：每个日志条目都有唯一的序列号，Leader 严格按序列号顺序复制日志，Follower 也按顺序接收和应用，保证操作的执行顺序一致；
- 异常处理：若某 Follower 复制日志失败（如网络中断），Leader 会持续重试，直到所有 Follower 同步至最新日志，确保集群状态最终一致；
- 与 TiDB Region 的关联：TiDB 将数据按范围划分为多个 Region，每个 Region 对应一个独立的 Raft Group，各 Group 独立执行 Raft 共识，保证了数据分片后的分布式一致性。
总结
- TiDB 中 Raft 日志是独立于 WAL 的逻辑日志，核心作用是通过分布式共识保证数据强一致性；
- Raft 日志复制的五阶段（Propose→Append→Replicate→Committed→Apply）是数据从请求到落地的完整链路，其中 “Committed” 阶段的半数共识是一致性的核心保障；
- Leader 选举和日志复制是 Raft 算法的两大核心，前者保障集群可用性，后者保障数据一致性，共同支撑 TiDB 分布式存储的可靠性。