万字长文，深入浅出讲解分布式数据库TiDB架构设计

发布时间：2025-11-05 05:33:40 来源：创站工坊 作者：IT科技

TiDB概述

TiDB 是万字长文一款开源 分布式关系型数据库，同时支持 在线事务处理（OLTP） 与 在线分析处理（OLAP） 的深入式数设计混合型（Hybrid Transactional and Analytical Processing, HTAP) 分布式数据库，具备水平扩容或缩容、浅出金融级高可用、讲解据库架构实时 HTAP、分布Kubernetes 云原生的万字长文分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性，深入式数设计支持在本地和云上部署。浅出

与传统的讲解据库架构单机 MySQL 数据库相比，TiDB 具有以下优势：

TiDB组件

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

计算引擎层：TiDB/TiSpark

OLTP计算引擎TiDB

TiDB Server 主要用于 OLTP 业务，属于 SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。

TiDB 层本身是 无状态的，实践中可以启动多个 TiDB 实例，通过 负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上，以达到 负载均衡 的效果。

TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。b2b信息网

OLAP计算引擎TiSpark

TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，它将 Spark SQL 直接运行在 分布式键值对存储层 TiKV 上，同时融合 TiKV 分布式集群的优势，并融入 大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。

TiFlash 和 TiSpark 都允许使用多个主机在 OLTP 数据上执行 OLAP 查询。TiFlash 是列式存储，它提供了更高效的分析查询。TiFlash 和 TiSpark 之间的关系，可类比于 Clickhouse 和 Spark。

分布式协调层：PD

PD (Placement Driver) 是整个 TiDB 集群的 元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。

PD 不仅存储集群元信息，同时还会根据 TiKV 节点实时上报的 数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是源码库 整个集群的“大脑” 。

此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

存储引擎层：TiKV/TiFlash

行存储TiKV

用于存储 OLTP 数据，采用 行存储格式，支持 事务机制，TiKV 本身是一个 分布式的 Key-Value 存储引擎。

存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。

列存储TiFlash

用于存储 OLAP 数据，和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以 列存储格式，主要的功能是为分析型的场景加速。

上图为 TiDB HTAP 形态架构，其中包含 TiFlash 节点。TiFlash 提供列式存储，且拥有借助 ClickHouse 高效实现的协处理器层。

TiFlash 以 低消耗不阻塞 TiKV 写入的方式，实时复制 TiKV 集群中的数据，并同时提供与 TiKV 一样的 一致性读取，且可以保证读取到最新的数据。TiFlash 中的 Region 副本与 TiKV 中完全对应，且会跟随 TiKV 中的 Leader 副本同时进行分裂与合并。

TiFlash 可以兼容 TiDB 与 TiSpark 两种计算引擎，TiDB 适合用于中等规模的 OLAP 计算，而 TiSpark 适合大规模的 OLAP 计算。

TiDB计算引擎

SQL层架构

用户的 SQL 请求会直接或者通过 Load Balancer 发送到 TiDB Server，TiDB Server 会解析 MySQL Protocol Packet，获取请求内容，对 SQL 进行语法解析和语义分析，制定和优化查询计划，执行查询计划并获取和处理数据。整个流程如下图所示：

表数据映射到KV

由于 TiDB 底层基于键值对存储数据，TiDB 表中的 行数据 需要按照一定格式映射转换为 键值对：

每行数据按照如下规则编码成 (Key, Value) 键值对：

Key: tablePrefix{TableID}_recordPrefixSep{RowID}

表索引映射到KV

TiDB 同时支持 主键索引 和 二级索引。与表数据映射方案类似，TiDB 为表中每个索引分配了一个 索引 ID，用 IndexID 表示。

Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue

Key: tablePrefix{TableID}_indexPrefixSep{IndexID}indexedColumnsValue{RowID}

KV映射示例

数据与 KV 的映射关系，定义如下：

假设表结构如下：

假设表数据如下：

TiKV存储引擎

TiKV Region

TiKV 可以看做是一个 巨大的、有序的 KV Map，为了实现存储的水平扩展，数据将被分散在多台机器上。对于一个 KV 系统，为了将数据 均衡分散在多台机器上，通常有两种方案：

利用哈希函数将数据节点均匀打散到一个 0 ~ 2^32 - 1 的顺时针哈希环上面，对于数据的新增、查询和删除等操作者，首先通过同一个哈希函数计算数据的哈希值，然后再哈希环上顺时针寻址，找到第一个数据节点进行数据访问。如图所示：

TiKV 选择了 连续分段哈希（Range） ，将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，将每一段叫做一个 Region，可以用 [StartKey，EndKey) 这样一个 左闭右开 区间来描述。每个 Region 中保存的数据量默认在 96 MiB 左右（可以通过配置修改）。

TiKV集群架构

TiKV 参考 Google Spanner 论文设计了 multi-raft-group 的副本机制。它将数据 按照 key 的范围 划分成大致相等的分片 Region，每一个 Region 会有多个副本（默认是 3 个），其中一个副本是 Leader，提供读写服务。

TiKV 通过 PD 对这些 Region 以及副本进行调度，以保证 数据负载 和 读写负载 都 均匀分散 在各个 TiKV 节点上，保证了整个集群资源的充分利用，并且可以随着 机器数量 的增加 水平扩展。

上图示意了一个典型的 TiKV 集群，中间有 4 个对等的 TiKV 节点，负责存放数据。其中一个 Region 存在3个副本，每个副本分布在不同的 TiKV 节点上。

右边是PD 集群，负责提供集群的元数据服务，比如 TiKV 节点信息和数据的路由信息，即数据存放在哪个 TiKV 节点上。

TiKV数据架构

按 Range 分片存在的问题是，数据的写入、读取可能集中在某一个 Region 上，造成计算资源、存储空间的倾斜。因此，当一个 Region 的数据量 超过阈值 时，TiKV 自动将其 分裂 成多个更小的 Region；当一个 Region 的数据量 低于阈值 时，TiKV 自动将其与相邻的 Region 合并。

TiKV 采用了 分层架构设计，将功能划分为四个层级，每一层都只负责自己的事情。

首先是网络层，TiKV 使用了高性能的 gRPC 作为网络通信框架。TiKV 对外暴露了多种形式的接口，包括支持事务的 KV 服务、高性能但不支持事务的纯 KV 服务，还有用于加速 SQL 查询的计算下推服务。

在网络层之下，是事务层。TiKV 实现了一个基于 Percolator 算法的事务处理机制，支持 乐观事务。此外，TiKV 还对 Percolator 做了改进，加入了对 悲观事务 的支持。

用户可以根据业务负载特点，灵活选择 事务模式：

事务层提供了快照隔离的特性和事务 ACID 属性中的 ACI（原子性、一致性、隔离性）特性，而 D（持久性）特性由下一层实现。

接下来是一致性层，该层提供了最基本的 键值操作接口，如 kv put/kv delete/kv get/snapshot。在一致性层内部，TiKV 实现了 Raft 一致性算法，保证 强一致性。

TiKV 还扩展了 Raft 算法，并引入了 multi-raft 算法，使数据能够自动分片。通过 multi-raft 算法，每个 Region 的大小可以保持在大约 96MB，而 PD（Placement Driver）则可以通过调度实现水平扩展。

最底层是 RocksDB，作为高效的键值存储引擎，它是 TiKV 真正存储数据的地方。RocksDB 提供了 持久化存储的能力，并被 TiKV 内部的各个层级用来读写数据。

每个 TiKV 实例中有 两个 RocksDB 实例，一个用于存储 Raft 日志（通常被称为 raftdb），另一个用于存储 用户数据 以及 MVCC 信息（通常被称为 kvdb）。kvdb 中有四个 ColumnFamily：raft、lock、default 和 write：

把 TiKV 集群架构 和 数据架构 整合起来，TiKV 集群的数据存储结构大致如图所示：

RocksDB原理

TiKV 使用 RocksDB 作为底层存储引擎，RocksDB 是一种 内嵌式 的 KV 存储引擎，因此可以将 RocksDB 理解为一个 单机持久化 Key-Value Map。

由于 RocksDB 是 TiKV 底层存储的核心引擎，所以接下来会花大篇幅介绍 RocksDB 的 内部构造 和部分 优化原理。

RocksDB 是由 Facebook 基于 Google LevelDB 开发的一款提供键值存储和读写功能的 LSM-tree 架构引擎。

可见，RocksDB 底层基于 LSM-tree 实现。LSM Tree（Log Structured Merge Tree，日志结构合并树） 是一种数据存储模型，而不是某一种具体的树型的数据结构。

LSM 树的核心思想是顺序 IO 远快于随机 IO，因此适用于写多读少的业务场景。

LSM Tree结构

LSM树是一种用于 键值存储 的 数据结构。LSM 的基本思想是将所有的数据修改操作（如插入、更新、删除）都记录在一个 顺序日志文件 中，这个日志文件又称为 预写日志（Write-Ahead Log，WAL） 。顺序日志文件的好处是 顺序写入，相比 随机写入 的 性能更好。

除了TiKV以外，Hbase、Cassandra和MongoDB等NoSQL底层的存储模型用的是LSM。

为了防止 内存断电 而丢失，LSM 在写入 Memtable 之前，会先将 增删查改操作 备份到 WAL 磁盘日志，在系统故障时，WAL 可以用来恢复丢失的数据。

WAL 是一个只允许追加的文件，包含一组更改记录序列。每个记录包含键值对、记录类型（Put / Merge / Delete）和校验和（checksum）。

Memtable 是 内存数据结构，可以使用 跳跃表 或 红黑树 来实现，以保持数据的 有序性。当 Memtable 达到一定的数据量后，Memtable 会转化成为 ****Immutable Memtable，同时会创建一个新的 Memtable 来存储新数据。

跳表：跳表是一种非常简单的链状二分搜索结构，期望时间复杂度 O(log n) ，最坏 O(n)

Memtable 存储的数据达到一定数量后，就会把它拷贝一份出来成为 Immutable Memtable。

Immutable Memtable 在内存中是 不可修改 的数据结构，它是处于 Memtable 和 SSTable 之间的一种 中间状态，目的是避免在转存过程中 不阻塞写操作。写操作可以由新的 Memtable 处理，避免由于 Memtable 直接写入磁盘造成的 IO 阻塞。

内存中的 Immutable Memtable 是有大小限制的，需要 定期持久化 到磁盘上的 SSTable。

SSTable 是 Sorted String Table 的简称，是一种 高性能 的 有序键值对 存储结构，由于键是有序的，查找键可以采用 二分搜索。

为了优化读取性能，LSM 树使用了 多层级 的 SSTable 文件。具体来说，RocksDB 的 SSTable 从 Level 0 到 Level N 分为多层，每层包含多个 SSTable 文件。层级越高的 SSTable 数据越新，层级越低的 SSTable 数据越旧。

SSTable 的基本组成部分包括：

SSTable 的优点包括：

RocksDB写操作

RocksDB 中写入操作的原理见下图：

RocksDB读操作

RocksDB 中读取操作的原理见下图：

Compaction操作

RocksDB 通过 追加写 的方式记录 数据修改操作：

通过这种方式，将磁盘的 随机写入 转换为 顺序写入，提高了写入性能，但也带来了以下问题：

因此，RocksDB 引入了 compaction 操作，依次将 L(N) 层 的数据合并到下一层 L(N+1) 层，同时清理标记删除的数据，从而降低 空间放大、读放大 的影响。

RocksDB 在逻辑上把 SSTable 文件划分成 多个层级（7 层），并且满足以下性质：

RocksDB 的 Compaction 操作分为两类，分别是 Minor Compaction 和 Major Compaction。

Minor Compaction 是指将 Immutable MemTable 转存为 SSTable 文件写入 L0 层

Major Compaction 是指 合并压缩 第 L(N) 层 的多个 SSTable 文件到第 L(N+1) 层

Major Compaction 的触发条件：

当 L0 层 SSTable 文件数 超过预定的上限（默认为4个）

当 L(N) 层文件的 总大小 超过(10 ^ i) MB

当某个 SSTable 文件 无效读取 的次数过多

布隆过滤器（Bloom Filter）

为了减小 读放大导致性能下降，RocksDB 采取了以下两种策略：

布隆过滤器底层使用一个 位数组（bit array） ，初始集合为空时，所有位都为 0：

当往集合中插入一个 数据 x 时，利用 k 个 独立的 哈希函数 分别对 x 进行散列，然后将 k 个散列值 按数组长度取余后，分别将位数组位置置为 1：

查找过程和插入过程类似，也是利用同样的 k 个哈希函数 对待 查找数据 按顺序进行哈希，得到 k 个位置。

布隆过滤器用于快速判断一条数据是否在集合中。其本质上是通过容忍一定的错误率，来换取时空的高效性。

RocksDB 并未使用 k 个哈希函数，而是用了 double-hashing 方法，利用一个哈希函数达到近似 k 个哈希函数的效果。

结语

本文详细介绍了 TiDB 的核心组件，尤其是用于 OLTP 的分布式 计算引擎 TiDB 和分布式 存储引擎 TiKV。一方面阐述了 TiDB 是如何将 关系型表数据 、索引数据 转换为 键值对 数据；另一方面，深度剖析了 TiKV 内部的架构设计和原理，尾篇大幅介绍了 TiKV 底层引入的 单机键值对 数据库 RocksDB 的原理，一定程度让大家知其然也知其所以然。本文抛砖引玉，关于 TiDB 内部的分布式通信、一致性原理、MVCC、GC清理算法、一些巧妙数据结构，仍需大家深入研究方可融会贯通，活学活用。

作者介绍

陈林，51CTO社区编辑，某零售银行龙头DevOps持续集成平台技术负责人，主导核心业务方案设计落地，推动产品架构持续演进。

相关文章