作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/6817b09f

作为新一代云原生分布式数据库产品，TiDB 的一个亮点是可以做到对业务透明。业务透明，简单理解下来就是说：虽然 TiDB 是一款分布式数据库，但是开发人员使用它对比使用传统的集中式数据库如 Oracle、MySQL 并没有什么区别。在 从《XX 分布式事务型数据库金融应用指南》看分库分表数据库使用复杂性 一文中，我们了解到分库分表架构中分片键设计的重要性，一旦前期的模型设计考虑不周，后期业务上线将面临诸多的问题。

而在 TiDB 里面，用户无须为怎样设计合理的分片键而担忧，这是因为 TiDB 在数据库内部将自动完成数据的切分、数据的合并、数据的均衡等。那么 TiDB 到底是怎么实现数据的自动均衡的呢？本文简要描述一下相关原理。

数据是怎么存储的？

在介绍数据均衡之前，我们需要先了解 TiDB 数据是怎么存储的。

集中式数据库的数据都是存储在一个实例中，分库分表下面则有多个实例，通过 SQL 路由层将数据分发到不同的实例。为了实现数据的冗余，通过 Redo 日志或 Binlog 日志实现主从复制。

以上是分库分表数据库的通用架构，可以看到分库分表的底层存储是多个单机数据库实例，每个单机实例又通过一主一从或一主多从来实现数据的复制。当集群规模较大时，集群的维护成本将会变得非常的高。

TiDB 的存储本质上是一个分布式的存储引擎，可以把它看成一个整体，而不是像上述架构中那样是多个主从实例拼凑而成。这个分布式的存储引擎中有两个非常重要的特点：

• 数据按照范围被切分成多个 Region 进行存储和分布。

• 数据是以 Region 为单位基于 Raft 的复制和管理。

Region 是一个尺寸很小的逻辑切片，每个 Region 和它的副本组成一个 Raft 组，这个组中有一个 Region 是主 (即 Leader，负责读写操作)。由于 Region 较小，可以想象这个分布式存储中有很多个 Raft 组在并行工作：Leader 的切换以 Region 为单位并行执行，数据的复制以 Region 为单位并行执行。这使得 TiDB 在数据的负载均衡处理上比分库分表架构更简单，对业务的侵入性也更小。同时，也可以发现 TiDB 的每个数据节点都可以对外承担读写服务，而分库分表架构中通常只有主实例所在节点在对外承载业务 (从实例一般用于承载只读业务)。

数据是怎么均衡的？

TiDB 中数据以 Region 为最小单位进行存储，较多的 Region 会自动分布到不同的数据节点上，这是由数据库的管控组件 PD(Placement Driver) 来完成的。PD 是 TiDB 集群的管理模块，同时也负责集群数据的实时调度，PD 通过调度来实现数据的负载均衡。那么 PD 是基于什么规则来调度呢？以及 PD 是怎么调度的呢？

PD 调度的基础—基于心跳机制的信息收集

PD 调度之前，首先得了解数据当前的分布情况，因此调度之前需要先进行信息收集，简单来说，调度需要知道每个数据节点的状态以及每个 Region 的状态。信息收集的事情并不是由 PD 发起的，而是由数据节点主动向 PD 来汇报的。数据节点向 PD 汇报的信息包含以下两个部分内容：

1. 节点的状态信息

每个数据节点 (称为 Store) 与 PD 之间存在心跳包，一方面 PD 通过心跳包来检测每个数据节点是否存活以及是否有新加入的数据节点，另一方面心跳包中携带该数据节点的状态信息，包括：总磁盘容量、可用磁盘容量、承载的 Region 数量、数据写入及读取速度、发送及接受的 Snapshot 数量、是否过载、labels 标签信息。

1. Region 的状态信息

每个 Raft 组的 Leader 和 PD 之间存在心跳包，用于汇报这个 Region 的状态，包括：Leader 位置、Followers 位置、掉线副本的个数、数据写入及读取速度。

PD 调度的执行—生成 Operator 并执行调度

PD 中默认包含一些调度器 (Scheduler)，这些调度器是独立运行的，分别服务于不同的调度目的，常用的调度器有 balance-leader-scheduler、balance-region-scheduler 等，如下图所示。这些调度器基于各种限制和约束后生成待执行的操作 (Operator)，Operator 会进入到一个队列中然后根据配置的并发度从队列中取出并执行。

上图所示的左三种调度器均为数据库默认包含的调度器，这意味着 TiDB 数据库默认会完成节点间的 Leader 平衡、Region 平衡以及读写热点 Region 的平衡，这也就解释了 TiDB 数据库中数据是怎么均衡的问题。Balance-leader-scheduler 和 Balance-region-scheduler 根据心跳数据对数据节点进行打分，并不断从得分较高的节点选择 Leader 或 Peer 迁移到得分较低的节点上。下图是某测试环境的 Leader 得分情况，可以看出数据库的 Leader 几乎是完全均衡的状态。

简单总结而言，TiDB 中的 PD 会基于实时发送的心跳包来判断节点之间的容量、负载、读写热点等的均衡情况，并以此为依据生成相应的调度策略并执行。