共计 2997 个字符，预计需要花费 8 分钟才能阅读完成。
数据库程度扩容的背景和挑战
首先咱们看程度扩容的背景。扩容的起因其实十分直观，一般来说次要是随着业务的访问量，或者是须要的规模扩充，而现有的容量或者性能满足不了业务的需要，次要体现在 TPS、QPS 不够或者时延超过了业务的容忍范畴，或者是现有的容量不能满足要求了，后者次要是指磁盘或者网络带宽。个别碰到这种问题，咱们就要扩容。扩容来说，其实比拟常见的就是两种形式，一种是垂直扩容，一种是程度扩容。这两种有不同的特点，优缺点其实也非常明显。
1.1 程度扩容 VS 垂直扩容
首先咱们看一下垂直扩容。垂直扩容，次要是进步机器的配置，或者进步实例的配置。因为，咱们晓得，大家在云上购买一个数据库或者购买一个实例，其实是按需分配的，就是说对用户而言，可能以后的业务量不大，只须要两个 CPU 或者是几 G 的内存；而随着业务的增长，他可能须要对这个实例进行扩容，那么他可能以后就须要 20 个 CPU，或者是 40G 的内存。这个时候，在云上咱们是能够通过对资源的管制来动静地调整，让它满足业务的需要——就是说能够在同一台机器上动静减少 CPU。这个扩容的极限就是——当整台机器的 CPU 和内存都给它，如果发现还不够的话，就须要筹备更好的机器来进行扩容。这个在 MySQL 外面能够通过主备切换：通过先选好一台备机，而后进行数据同步；等数据同步实现当前，进行主备切换，这样就能利用到当初比拟好的那台机器。大家能够看到，这整个过程当中，对业务来说基本上没有什么影响——进行主备切换，如果换 IP 的话，其实是通过前端的或者 VIP 的形式，对业务来说基本上没有什么影响。那么它一个最大的不好的中央就是，它依赖于单机资源：你能够给它提供一个更好的机器，从而满足一定量的要求。而随着业务更加疾速的倒退，你会发现当初能提供的最好的机器，可能还是满足不了，相当于扩不上来了。因而，垂直扩容最大的毛病就是，它依赖于单机的资源。
跟垂直扩容比照，另外一种形式咱们叫程度扩容。程度扩容最大的长处是解决了垂直扩容的问题——实践上程度扩容能够进行有限扩容，它能够通过减少机器的形式来动静适应业务的需要。
程度扩容和垂直扩容相比，它能够解决垂直扩容的问题，然而会引入一些其余的问题。因为程度扩容比垂直扩容更加简单，上面咱们剖析下可能遇见的问题，以及前面咱们会介绍 TDSQL 的解决方案：
首先 ，在垂直扩容外面，零碎通过扩容当前，其实数据总体来说还是存在一个节点，一主多备架构中，备机上也存储着所有数据。而程度扩容过程中数据会进行拆分，面临的第一个问题是，数据如何进行拆分？因为如果拆分不好，当呈现热点数据时，可能后果就是，即便曾经把数据拆分成很多份了，然而存储热点数据的独自节点会成为性能瓶颈。
第二点 ，在整个程度扩容过程中，会波及到数据的搬迁、路由的扭转。那么整个过程中是否做到对业务没有感知？或者是它对业务的侵入性大略有多少？
第三 ，在整个扩过程中，因为方才有这么多步骤，如果其中一步失败了，如何可能进行回滚？同时，在整个扩容过程中，如何能保障切换过程中数据高一致性？
再者 ，在扩容当前，因为数据拆分到了各个节点，如何能保障扩容后的性能？因为实践上来说，咱们是心愿我随着机器的减少，性能也能做到线性晋升，这是现实的状态。实际上在整个程度扩容的过程中，不同的架构或者不同的形式，对性能影响是比拟大的。有时候会发现，可能扩容了很多，机器曾经减少了，然而性能却很难做到线性扩大。
同样的，当数据曾经拆分成多份，咱们如何持续保障数据库分布式的个性？在单机架构下，数据存储一份，相似 MySQL 反对本地做到原子性——能够保障在一个事物中数据要么全副胜利，要么全副失败。在分布式架构里，原子性则只能保障在单点外面数据是一致性的。因而，从全局来说，因为数据当初跨节点了，那么在跨节点过程中怎么保障全局的一致性，怎么保障在多个节点上数据要么全副写胜利，要么全副回滚？这个就会波及到分布式事务。
所以大家能够看到，程度扩容的长处很显著，它解决了垂直扩容机器的限度。然而它更简单，引入了更多的问题。接下来大家带着这些问题，上面我会介绍 TDSQL 如何进行程度扩容，它又是如何解决方才说的这些问题的。
2 TDSQL 程度扩容实际
首先咱们看一下 TDSQL 的架构。TDSQL 简略来说蕴含几局部：
第一局部是 SQL 引擎层：次要是作为接入端，屏蔽整个 TDSQL 后端的数据存储细节。对业务来说，业务拜访的是 SQL 引擎层。
接下来是由多个 SET 组成的数据存储层：分布式数据库中，数据存储在各个节点上，每个 SET 咱们当做一个数据单元。它能够是一主两备或者一主多备，这个依据业务须要来部署。有些业务场景对数据安全性要求很高，能够一主三备或者一主四备都能够。这个是数据存储。
还有一个是 Scheduler 模块，次要负责整个零碎集群的监控、管制。在零碎进行扩容或者主备切换时，Scheduler 模块相当于是整个零碎的大脑一样的管制模块。对业务来说其实只关注 SQL 引擎层，不须要关注 Scheduler，不须要关注数据是怎么跨节点，怎么分成多少个节点等，这些对业务来说是无感知的。
整个扩容流程大家能够看一下：一开始数据都放在一个 Set 上，也就是在一个节点外面。那么扩容其实就是会把数据扩容到——这外面有 256 个 Set，会扩容到 256 台机器上。整个扩容大家能够看到有几个要点：
一开始尽管数据是在一个节点上，在一台机器上，然而其实数据曾经进行了拆分，图示的这个例子来说是曾经拆分成了 256 份。
程度扩容，简略来说就是把这些分片迁徙到其余的 Set 上，也就是其余的节点机器上，这样就能够减少机器来为提供零碎性能。
总结起来就是说，数据一开始曾经切分好了，扩容过程相当于把分片迁到新的节点，整个扩容过程中，节点数是减少的，能够从 1 扩到 2 扩到 3，甚至扩到最初能够到 256，然而分片数是不变的。一开始 256 个分片在一个节点上，扩成两个节点的话，有可能是每 128 个分片在一个节点上；扩到最初，能够扩到 256 个节点上，数据在 256 台机器，每台机器负责其中的一个分片。因而整个扩容简略来说就是搬迁分片。具体细节咱们前面会讲到。
在公有云或者是私有云上，对整个扩容 TDSQL 提供了一个对立的前台页面，用户在应用的过程中十分不便。
咱们看一下这个例子。当初这个案例中有两个 Set，也就是两个节点，每一个节点负责一部分的路由，第一个节点负责 0 -31，另一个名字是 3，负责的路由信息是 32-63。当初是两个节点，如果要进行扩容，在前台页面上咱们会有一个“增加 Set”的按纽，点一下“增加 Set”，就会弹出一个对话框，外面默认会主动抉择之前的一个配置，用户能够本人自定义，包含当初这个 Set，须要多少资源以及内存、磁盘的调配等。
此外，因为扩容要进行路由切换，咱们能够手动抉择一个工夫，能够主动切换，也能够由业务判断业务的理论状况，人工操作路由的切换。这些都能够依据业务的须要进行设置。
第一步创立好当前，方才说大脑模块会负责调配各种资源，以及初始化，并进行数据同步的整个逻辑。最初，大家会看到，原本第一个节点——原来是两个节点，当初曾经变成三个节点了。扩容之前，第一个节点负责是 0 -31，当初它只负责 0 -15，另外一部分路由由新的节点来负责。所以整个过程，大家能够看到，通过网页上点一下就能够疾速地从两个节点增加到三个节点——咱们还能够持续增加 Set，持续依据业务的须要进行一键扩容。
