上述TiDB 架构图展示了 TiDB 系统中的各个组件及它们之间的交互方式，核心组件包括 TiDB Server、TiKV、PD（Placement Driver）集群、TiFlash，整个系统旨在支持混合事务和分析处理 (HTAP) 的场景。

<!-- 小贴士 -->
在 TiDB V2 版本时，TiDB 引入了 TiSpark 组件，旨在借助 Apache Spark 的分布式计算能力，为用户提供快速处理大规模数据集的分析和查询功能。​从 TiDB 4.0 版本开始，TiFlash 组件被引入，并逐渐成为 TiDB 进行 OLAP 查询的首选工具。TiFlash 通过列存储和 MPP（大规模并行处理） 模式，显著提升了数据分析效率。​TiSpark 是 TiDB 早期的大规模数据分析解决方案，尤其是在 TiFlash 出现之前，它是主要的分布式 OLAP 查询工具。​尽管 TiFlash 后来成为 OLAP 的首选组件，但 TiSpark 并未被取代。它仍在需要复杂分布式计算的场景中使用，尤其是 Apache Spark 提供的丰富数据处理能力，使 TiSpark 在特定应用场景下依然有重要价值。

 在 TiDB 集群架构中，TiDB Server 作为前端的 SQL 处理组件，负责接收并解析来自应用程序的 SQL 请求。TiDB 完全兼容 MySQL 5.7 语法，这使得现有的 MySQL 用户可以无缝迁移到 TiDB，并继续使用他们熟悉的 SQL 语句进行操作。
 TiDB Server 的一个重要特性是**无状态**设计。数据不存储在 TiDB Server 上，而是存储在 TiKV/TiFlash 集群中。TiDB Server 的任务是处理 SQL 语句的生命周期：包括**解析**语法、**编译**查询、**优化**执行路径，以及生成最终的**执行计划**。生成的执行计划会被下发到 TiKV（TiDB 的分布式存储引擎）执行，确保高效的数据操作。
 由于 TiDB Server 无状态，它具备出色的**横向扩展性**。在高并发场景下，当大量 session 会话集中访问某个 TiDB Server 节点时，可以通过简单地增加新的 TiDB Server 节点来扩展集群的吞吐能力。这种横向扩展机制可以迅速均衡集群中的负载，减少单个节点的压力，保持系统的稳定性与高效性。

  TiKV 是 TiDB 的存储引擎集群，负责持久化数据。虽然表结构是通过 SQL 语句如 `CREATE TABLE` 创建的，但数据并非直接以表的形式存储在 TiKV 上。相反，数据表会被 TiDB Server 转换为一个个**存储单元**，这些单元称为**Region**。每个 Region 的大小通常在 96MB 到 144MB 之间，一个表会被切分为多个 Region，分布式存储在 TiKV 集群中。
  TiKV 使用 **Raft 协议** 为每个 Region 提供高可用性。默认情况下，每个 Region 会有三个副本，分布在不同的节点上，以确保数据的可靠性。根据实际需求，副本数量可以灵活配置，例如配置为五副本来提高容错能力。Raft 协议保证了即使部分节点出现故障，数据仍然可用。
  TiKV 集群具备良好的**水平扩展性**，当存储需求增加或减少时，可以通过增加或减少 TiKV 节点的数量实现**弹性扩展**或**缩容**，满足业务需求的动态变化。
  此外，TiKV 实现了**分布式事务**和**多版本并发控制（MVCC）**，使其能够处理高度一致性和复杂事务的场景。关于分布式事务的细节将在后续章节中深入探讨。
  TiFlash 是 TiDB 生态中的另一种存储引擎，它存储的数据与 TiKV 相同，同样基于 Region 的结构。然而，TiKV 采用**行存**的存储方式，而 TiFlash 则是**列存**。列存擅长处理大规模的分析型查询，特别适用于需要对大表进行统计分析的场景。

  PD（Placement Driver） 是 TiDB 集群的核心组件之一，通常被称为 TiDB 集群的“大脑”，其主要职责是管理集群的**元数据信息**。可以通过一个例子来说明：假设表 T 的数据被切分成多个 Region，这些 Region 分布在多个 TiKV 或 TiFlash 节点上，PD 负责记录这些 Region 与存储节点之间的对应关系，这些信息即为**元数据**，并存储在 PD 集群中。
  当 TiDB Server 解析、编译并优化完一条 SQL 语句后，生成的执行计划需要查询表 T1 的数据。此时，TiDB Server 首先会向 PD 查询表 T1 的元数据信息，以确定该表的数据分布在哪些 TiKV 或 TiFlash 节点上。
  PD 还负责管理 TiDB 中的**全局时间戳**。每条 SQL 语句在执行时都会获取一个**TSO（Timestamp Oracle）**，这是一个唯一且单调递增的时间戳，用于标识 SQL 语句的开始时间。与传统的时、分、秒表示不同，TSO 像一个不断增长的计时器，确保了 SQL 执行的全局顺序。在事务处理中，每个事务有两个关键的 TSO：一个是**开始 TSO**，另一个是**提交 TSO**，这两个时间戳帮助保证了分布式事务的正确性和一致性。
  在后续章节中，我们将深入讨论 PD 的工作原理和实现细节。

   当用户发起会话连接 TiDB 时，首先到达的是 TiDB Server。TiDB Server 作为 SQL 请求的前端处理组件，当会话数激增，导致节点资源不足时，可以通过**动态扩容**来增加 TiDB Server 节点，从而分担负载。由于 TiDB Server **不存储数据**，扩容可以快速有效地分流各节点的会话压力。而在会话数量下降时，还可以灵活地**回收节点**，以提高资源利用率。
   对于一条 SQL 语句，TiDB Server 不会立即执行，而是首先对 SQL 进行**解析**和**编译**，生成一个**执行计划**。执行计划类似于一个操作指南，指引 TiDB 该如何执行 SQL，例如是否应该使用索引或进行全表扫描。TiDB Server 的角色就是将 SQL 转换为执行计划，随后通过该计划在后端的 TiKV 或 TiFlash 上执行数据操作。
   在数据插入过程中，TiDB Server 还负责将表数据转换为**键值对（key-value）\**格式。与传统数据库逐行存储不同，TiDB 以键值对的方式组织数据。TiDB Server 将表数据转换为键值对后，分发到 TiKV 或 TiFlash 存储引擎中，后者会将这些键值对进一步组织成多个\**Region**，以实现分布式存储。
  此外，TiDB Server 还处理一系列的 **DDL（数据定义语言）** 操作，如建表、创建索引等。值得注意的是，TiDB 的 DDL 操作不会阻塞线上业务，确保了系统的高可用性和稳定性。
  TiDB Server 另一个重要功能是**垃圾回收（GC）**。当 TiKV 或 TiFlash 中的表数据经历多次更新时，会产生大量历史版本数据。随着历史版本的增加，存储占用会不断扩大，并且可能导致查询性能下降。为此，TiDB Server 会定期（默认每 10 分钟）对 TiKV 和 TiFlash 中的历史数据进行清理，删除不再需要的旧版本记录，进而提升查询性能并减少存储开销。

<!-- 小贴士 -->
TiDB 使用 MVCC（多版本并发控制） 来实现事务。新写入的数据不会直接覆盖旧数据，而是保留多个版本，并通过时间戳区分。为了避免历史数据积累，垃圾回收（GC） 机制用于清理不再需要的旧版本数据。​GC 机制：1) GC Leader 选举： 一个 TiDB 实例会被选举为 GC Leader，负责控制集群中的 GC 操作。2) 定期触发： GC 默认每 10 分钟触发一次。3) Safe Point 计算： GC 首先计算出一个 safe point（安全时间点），它是当前时间减去 GC life time（默认 10 分钟）。GC 会删除早于 safe point 的过期数据，确保 safe point 之后的快照数据正确。4) 事务保护： 如果有长时间运行的事务，GC 不会删除该事务开始之前的数据，确保事务的一致性和可用性。5) 顺序执行：如果一次 GC 运行时间较长，下一轮 GC 不会在当前 GC 结束前启动。​# 注意，不同TiDB 版本，GC机制略有不同，比如从 TiDB 5.0 版本开始，CENTRAL GC 模式（需要 TiDB 服务器发送 GC 请求到各个 Region）已被废弃。自 TiDB 3.0 版起默认的 DISTRIBUTED GC 模式 成为唯一运行模式。此模式下，GC 由各个节点分布式执行，无需集中请求，提高了系统的效率和稳定性。

   如上图所示，每个 TiKV 节点都包含事务处理层、MVCC 层、Raft 层以及 RocksDB 的存储支持，所有节点协同工作，确保分布式系统中的数据一致性、高可用性和高性能，接下来将分别介绍TiKV节点中个组成成分及TiKV核心功能。

   作为一款分布式数据库，TiDB 的核心目标之一是确保**数据持久化**，避免数据丢失。在 TiDB 的存储引擎 TiKV 中，数据持久化是通过底层的 **RocksDB** 来实现的。RocksDB 是 TiKV 的核心存储引擎，每个 TiKV 实例中运行着两个 RocksDB 实例：一个是用于存储用户数据及 MVCC 信息的 **RocksDB kv**（简称 kvdb），另一个是用于存储 Raft 日志的 **RocksDB raft**（简称 raftdb）。

  由于 TiDB 面向金融级应用，单机 RocksDB 无法满足高可用需求。因此，在 RocksDB 之上增加了 **Raft 协议** 这一层来确保数据的高可用性和一致性。
  Raft 的核心作用是通过多副本机制保障数据的一致性。每个 **Region**（存储单元，通常大小为 96MB）会在多个 TiKV 节点上存储多个副本，TiDB 默认配置三个副本。在这三个副本中，只有一个副本被选举为 **Leader**，负责读写操作，其余副本为 **Follower**，只能接收 Leader 的更新。
  当数据发生修改时，Raft 协议会首先将修改应用到 Leader 副本的 rocksdb kv 中，随后将该修改同步到其他两个 Follower 副本。只有当大多数副本确认接收到修改时，修改才算真正成功。通过这种方式，TiDB 实现了数据的**强一致性**和**高可用性**。

<!-- 小贴士 -->​1) 自动化的多副本恢复在 TiDB v6.1.0 之前，如果由于物理机故障导致多个 TiKV 的 Region 副本丢失，用户需要停机所有 TiKV 并使用 TiKV Control 逐一进行恢复。从 TiDB v6.1.0 开始，这一过程被完全自动化，用户不再需要停机，且恢复过程不会影响其他正常的在线业务。通过 PD Control 触发在线有损恢复数据，大大简化了恢复步骤，缩短了恢复时间，并提供了更加友好的恢复摘要信息。​2) 支持在线修改配置在 TiDB v6.1.0 之前的版本中，配置参数的变更需要重启整个 TiDB 集群才能生效，这对在线业务造成了一定的影响。而在 TiDB v6.1.0 中，引入了在线修改配置的功能。现在，参数修改后无需重启即可生效，大幅提升了在线业务的灵活性和稳定性。

  在 Raft 之上，TiKV 实现了**MVCC（Multi-Version Concurrency Control）**，用于解决并发读写问题。MVCC 通过为每个 Key 存储多个版本的数据来实现。当客户端 A 正在写入一个 Key 时，客户端 B 可以同时读取这个 Key 的早期版本，而不会阻塞。这种多版本控制机制避免了读写操作之间的互斥冲突，极大提升了系统的并发性能。
   TiKV 中的 MVCC 是通过在 Key 后面附加一个版本号来实现的。每次写操作都会生成一个新的版本号，版本号较大的数据会被存放在前面，版本号较小的则存放在后面。通过这种机制，TiKV 能够根据 Key 和版本号查询出不同版本的数据。

  在高可用、持久化和 MVCC 基础上，TiDB 还实现了**分布式事务模型**，支持**两阶段提交**。TiDB 的事务机制确保了在分布式环境中，即使在多个节点上同时进行事务操作，数据的一致性依然能够得到保障。
  总结：可以将 TiKV 内部的这些层次结构类比为**TCP/IP 协议栈**。从最基础的 **RocksDB** 单机存储引擎开始，逐层添加协议：Raft 协议确保副本一致性，MVCC 解决并发冲突，分布式事务机制提供了可靠的事务管理。通过这些层次的组合，TiKV 实现了一个完整的、面向分布式场景的高可用数据库系统。

  Coprocessor 是 TiDB 中的一项关键技术，它充分发挥了**分布式计算**的优势。虽然 TiKV 存储引擎的数据分布在多个节点上，且跨节点访问可能会带来一定的网络延迟，但每个节点都配备了 CPU 资源，可以利用这些资源进行**本地计算**，从而减轻 TiDB Server 的计算负载。
  例如，当执行一个带有条件的查询 `WHERE age > 25` 时，传统数据库架构可能会将所有相关数据从存储引擎中读取到数据库服务器上，再进行条件过滤。而在 TiDB 中，通过 Coprocessor，可以将这个过滤操作下推到各个 TiKV 节点。在每个节点上直接执行 `age > 25` 的过滤操作，只返回符合条件的数据。这不仅减少了网络传输的数据量，还降低了 TiDB Server 的计算压力。
  除了基本的过滤操作，Coprocessor 还支持其他类型的计算下推，如**投影**（选择需要的列）和**聚合**操作。通过这些下推操作，TiDB 实现了一个**分布式计算模型**，将计算任务分发到多个存储节点上并行处理，从而提升了查询的执行效率。
  简言之，Coprocessor 利用存储节点的计算资源，使得分布式计算不仅仅是数据的分布式存储，更是在分布式环境中高效地执行计算操作。

<!-- 小贴士 -->​从 TiDB 4.0 版本开始，TiDB 支持下推计算结果缓存功能（Coprocessor Cache）。当该功能开启后，TiDB 实例会在本地缓存下推给 TiKV 的计算结果，从而在特定场景下显著提升查询性能。从 TiDB 5.0 GA 版本起，Coprocessor Cache 被默认开启，使查询过程更加高效。​Coprocessor 是 TiKV 中负责数据读取和计算的核心模块，其实现方式类似于 HBase 中的 Coprocessor 的 Endpoint 功能，也可以与 MySQL 的存储过程进行类比。​TiDB 从 4.0 起支持下推计算结果缓存（即 Coprocessor Cache 功能）。开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，在部分场景下起到加速效果。从5.0 GA开始 默认开启 Coprocessor cache 。​TiKV Coprocessor 主要处理的读请求可以划分为以下三类：DAG（Directed Acyclic Graph）描述：DAG 是 TiKV 执行物理算子的核心框架，它通过构建一个无环有向图来执行下推的 SQL 计算任务。在存储层执行计算，能够生成中间结果，从而减少 TiDB 的计算负担和网络传输压力。应用场景：大多数 SQL 查询都会通过 DAG 下推到 TiKV 进行处理，包括表扫描、索引扫描、过滤、聚合和排序等操作。通过分布式执行这些操作，可以显著提升查询效率。特点：DAG 是 Coprocessor 的核心任务，在实际场景中，它通过在 TiKV 上分布式执行 SQL 任务，有效降低了 TiDB 的计算开销和网络延迟。​Analyze描述：Analyze 请求用于分析表或索引的数据分布情况，生成统计信息，以帮助 TiDB 优化器做出更高效的查询计划。应用场景：当执行 ANALYZE TABLE 命令时，TiDB 将分析任务下推到 TiKV，统计数据包括表的行数、列的数据分布以及直方图等。这些统计信息会被持久化并供优化器使用，从而生成更优的执行计划。特点：Analyze 请求对查询性能优化至关重要，尤其是在数据频繁更新的场景下。优化器依赖最新的统计信息，确保查询计划能够最大化利用现有资源。​CheckSum描述：CheckSum 请求用于在数据导入或迁移后验证数据一致性。它通过计算表的 CheckSum 值，确保数据在不同节点或存储引擎之间的一致性。应用场景：CheckSum 通常用于数据迁移后的验证。例如，在使用 TiDB Lightning 导入大量数据后，CheckSum 可以确保导入数据与源数据完全一致。特点：CheckSum 提供了一种有效的数据一致性校验机制，尤其适用于数据导入和跨存储引擎操作，确保数据完整准确。​# 更多关于Coprocessor的内容可参考 《TiKV 源码解析系列文章（十四）Coprocessor 概览》 和 《TiKV 源码解析系列文章（十六）TiKV Coprocessor Executor 源码解析》 两篇文章

   当 SQL 语句在 TiDB Server 中执行时，首先需要了解目标数据在哪些 TiKV 节点上存储。这些**元数据信息**由 PD 组件管理，PD 会向 TiDB Server 提供相应的信息，指引其前往正确的 TiKV 节点获取表 T 的数据。此外，PD 还负责分配诸如表 ID、事务 ID 等**全局唯一标识符**。
  每条用户发起的 SQL 语句在开始执行时，都需要生成一个**TSO（Timestamp Oracle）**，即一个全局时间戳。PD 通过其授时功能生成 TSO，并将其提供给 TiDB Server。对于事务操作，TSO 同样用于记录事务的开始时间和提交时间，确保在分布式系统中事务的顺序性和一致性。
  在 TiKV 中，表的数据是分布式存储的。随着表的增删改操作增多，某些表的 Region 可能会过度集中在某个 TiKV 节点上，导致该节点的负载不均衡，产生性能瓶颈。为了避免这种情况，TiKV 节点会定期向 PD 汇报其状态，包括 Region 的分布和读写压力等信息。PD 会根据这些信息进行**负载调度**，将某些 Region 迁移到负载较低的 TiKV 节点上，从而平衡集群中的数据分布和访问压力。

<!-- 小贴士 -->​每个 Raft Group 的 Leader 会定期向 PD 发送心跳包，汇报 Region 的状态。心跳信息主要包括以下内容：1) Leader 的位置2) Followers 的位置3) 掉线副本的数量4) 数据的读写速度PD 通过这些心跳消息持续收集集群的状态信息，并基于这些数据做出调度决策。

  上图是TiDB V2 版本体系架构图，在该图中，可以看到 TiDB 体系架构中含有 TiSpark组件，没有TiFlash组件。