作为新一代云原生分布式数据库产品，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汇报的信息包含以下两个部分内容：
- 节点的状态信息
每个数据节点(称为Store)与PD之间存在心跳包，一方面PD通过心跳包来检测每个数据节点是否存活以及是否有新加入的数据节点，另一方面心跳包中携带该数据节点的状态信息，包括：总磁盘容量、可用磁盘容量、承载的Region数量、数据写入及读取速度、发送及接受的Snapshot数量、是否过载、labels标签信息。
- 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会基于实时发送的心跳包来判断节点之间的容量、负载、读写热点等的均衡情况，并以此为依据生成相应的调度策略并执行。