TiKV Raft 快照全流程丨TiKV 源码解读（二十二）

导读

TiKV 是一个支持事务的分布式 Key-Value 数据库，目前已经是 CNCF 基金会的顶级项目。它通过 Raft 协议实现数据的高可用性和强一致性，是 TiDB 分布式数据库系统的重要组成部分。本文作为 TiKV 源码解读系列的增补，详细介绍了 TiKV 8.2.0 版本中 Raft 快照的生成、发送、接收和应用的具体实现。

在 Snapshot 的发送和接收中，我们详细介绍了 Raft 快照的发送和接收机制。本篇文章作为前文的补充，将概述 TiKV 中 Raft 快照的整体流程，并详细介绍涉及的代码路径。本文所讨论的代码基于最近的 8.2.0 版本。

在 TiKV 中，数据空间被切分成各个连续的范围，称为 Region。每个 Region 由一个单独的 Raft 组管理，基于 Raft 协议保证容错性。每个 Raft 组包含多个 Peer，每个 Peer 在不同的 TiKV 节点上运行。

图 1. TiKV 中的 Region 和 Raft 组

在 Raft 协议中，Leader 节点负责将最新的日志条目通过 Append RPC 发送给 Followers，以确保所有节点的数据一致性。为防止磁盘空间的无限制增长，Leader 节点会定期清理过时的本地 Raft 日志。然而，如果某个 Follower 落后太多，以至于其请求的日志条目已经被 Leader 清理，传统的 Append RPC 将无法继续同步数据。在这种情况下，Leader 节点将采取替代措施，向落后的 Follower 发送一个 Raft 快照。这个快照包含了 Region 在某一特定时间点的完整状态快照，不仅包括存储于 RocksDB 中的数据，还有 Raft 协议的状态信息，例如任期号（term）和所对应的日志索引（index）。在 TiKV 的实际应用中，快照机制通常在 Region 初始化、发生分裂或进行扩展等关键操作时被触发，以确保数据的一致性和系统的稳定性。

TiKV 中的 Raft 快照过程大致分为四个阶段：

1. 生成: Raft Leader 生成一份快照，记录下 Raft 和 RocksDB 在当前时间点的状态。

**2. 发送:**Raft Leader 通过网络把快照发送给 Follower。

3. 接收: Raft Follower 接收快照并暂时存储。

4. 应用: Raft Follower 将快照应用到 Raft 状态机和 RocksDB 数据中。

以下图表更详细地描述了快照过程:

图 2. TiKV 中的 Raft 快照过程

本文将详细介绍 Raft 快照实现的原理和流程，这个部分将介绍核心环节的设计思路，在代码路径详解中我们会逐步介绍细节。

快照元数据和数据的分离

Raft 消息 (protobuf definition：https://github.com/pingcap/kvproto/blob/df42997c2c57536219c67253966ede4d61d25757/include/eraftpb.proto#L77) 有一个 snapshot 字段，可以存储快照数据和元数据。一个简单的做法