共计 2471 个字符，预计需要花费 7 分钟才能阅读完成。
导读
本文探讨了分布式数据库在在线扩容方面的挑战，具体解释了个别分布式数据库和 TiDB 在扩容机制上的不同。个别分布式数据库在进行在线扩容时，须要从新均衡数据分布，可能会影响零碎的可用性和 IO 耗费。相比之下，TiDB 的存算拆散架构使得扩容对业务影响较小。
作者：爱喝自来水的猫 起源公众号：数据源的技术后花园。
昨天和他人交换 PingCAP TiDB 时，这位同学对“TiDB 在线扩容对业务简直没有影响”这一点示意不太了解，诧异 TiDB 到底是怎么做到的。细聊下来，发现这位同学是一位次要负责集中式和晚期分布式架构数据库的 DBA 人员，比拟相熟 Oracle、Greenplum。于是我有点了解他的诧异了，因为 Oracle 和 Greenplum 我也是有一点点教训，本文简略针对个别分布式数据库和 TiDB 在扩容机制上谈一点集体的了解。
个别分布式数据库在线扩容是怎么做的
集中式数据库因为其架构自身的限度，一般来说想要实现在线扩容是比拟艰难的，这里暂且不予探讨，咱们次要理解一下个别分布式数据库的扩容是如何进行的。不论是 Greenplum 这种 MPP 数据库，还是其它的分库分表数据库，为了实现数据的平衡散布，通常须要在表上定义相干的散布键。通过散布键，再联合哈希算法，能够把数据哈希散列到不同的数据节点中，相似于 hash（key）% N（key 代表散布键，N 代表数据节点编号）。举个例子，如果一个分布式数据库有 3 个数据节点，表的散布键为 ID（ID 是一个递增序列），那么基于哈希算法散列后数据的散布大抵如下图所示：
当初咱们须要扩容一个节点，从原来的 3 节点扩容到 4 节点。为了保障原来哈希散列后果的一致性数据须要从新均衡，均衡后的数据分布应该如上面图中所示。能够发现，这个时候大部分的数据根本都搬迁了一遍。先不说数据的迁徙是否对业务造成阻塞，光是这现有的大面积数据平衡足以导致整个零碎的 IO 耗费极高，重大影响整个零碎的可用性。
Greenplum 在官网文档中还明确指出“正在被从新散布的表或者分区会被锁定并且不可读写。当其从新散布实现后，惯例操作才会持续 ”。能够明确的说，Greenplum 晚期版本外面基本就不 反对所谓的“ 在线”扩容。
时代在提高，数据库技术也在提高。为了尽可能实现在线扩容的能力，Greenplum 数据库包含其余的分库分表数据库开始引入一些新的算法来优化此事。一致性哈希算法 开始被广泛利用，它与传统哈希算法最次要的不同是 不再应用节点编号来进行散列，而是应用 2^32 这样一个固定值做取模运算。一致性哈希算法将表中的数据和节点编号映射到一个圆环上，当减少节点时影响的数据范畴只是圆环上的一小段数据范畴。比方下图中减少节点 4，影响的数据只有节点 1 到节点 4 之间的这部分数据。
一致性哈希算法解决了数据重散布时大量数据搬迁的问题，缩小了数据搬迁时的网络 IO 和磁盘 IO。不过要真正实现不影响业务，还须要改良数据重散布外部的机制，比方 重散布时锁表 等问题。
TiDB 的扩容是怎么做的以及为什么它简直不影响业务?
TiDB 的扩容机制离不开 TiDB 整体的架构实现。作为一个存算拆散的原生分布式架构，TiDB 集群次要由三大模块形成：用于集群元数据管理及集群调度的 PD、用于接管内部申请并解析编译执行 SQL 的计算引擎 TiDB Server 以及用于数据存储以及多正本数据一致性保障的存储引擎 TiKV/TiFlash。
基于存算拆散的架构，TiDB 能够独自进行计算层扩容和存储层扩容。计算层的扩容绝对简略，因为 TiDB Server 自身是无状态的。TiDB Server 节点不长久化数据，每个节点也是齐全对等的，当 TiDB Server 计算资源不够了，只须要减少 TiDB Server 节点，而后批改下层的负载平衡组件将客户端连贯平衡散发到新的 TiDB Server 节点即可（目前大多数负载平衡组件都反对动静批改配置）。因而，计算节点的扩容齐全不会影响现有的业务。
针对存储节点，TiKV 的扩容与个别分布式数据库的扩容机制是齐全不同的，这次要因为 TiKV 是一种 基于 Multi Raft 协定的分布式存储引擎，而不是像 Greenplum 或分库分表那种底层是多个 MySQL 或 PG 的单机数据库。
如果某集群要从 3 个 TiKV 节点扩容到 4 个 TiKV 节点，扩容步骤大抵能够概括如下：
1.扩容 TiKV 节点。集群减少一个 TiKV 4 节点，此时 TiKV 4 上没有任何 Region。PD 节点辨认到新的 TiKV 节点启动负载调度机制，计算哪些 Region 须要迁徙到 TiKV 4。
2.调度算法确定迁徙 Region。PD 节点依据调度机制，确定将哪些 Region 正本迁徙到 TiKV 4 上（如果开始 3 个节点上各有 6 个 Region，均匀到 4 个节点后每个节点的 Region 数为 18/4=4~5 个正本）。PD 对 TiKV1~3 上 Region 对应的 Leader 正本发动复制指令。
3.复制 Region 到新节点。在 TiKV 上创立要复制的 Region 的正本，通过 Raft 机制开始复制数据。此过程中利用读写访问不受影响，不过因复制过程产生的 IO 耗费可能会对性能产生一点影响，不过 TiDB 自身提供了流控，能够动静调整复制的速度。
4.删除多余 Region。Region 复制实现且数据统一后，PD 将发动删除原有正本指令，保障每个 Region 的正本只有 3 个。
5.Leader 从新平衡。PD 依据调度机制，须要平衡 Leader 正本，将一部分 Region 的 Leader 切换到新增节点 TiKV 4 上，保障 Leader 的平衡。Leader 切换实现后，读写业务将主动路由到 TiKV 4 上实现业务负载平衡。
上述步骤简略了解下来就是说，TiKV 的扩容是一种 学生成正本再迁徙 Leader 的一个过程，扩容对业务有影响的中央次要在于生成正本产生的 IO 耗费以及 Leader 切换的影响。对于前者，数据库有流控机制能够保障对业务简直没有影响；对于后者，一方面 Leader 的切换自身工夫十分短，另一方面当 TiDB 意识到 Region 迁徙后也可能通过外部重试保障前端业务的失常执行。因而，存储节点的扩容也简直不会影响现有的业务。
