引言
自去年 12 月底公布后，腾讯会议 40 天更新 14 个版本，8 天紧急扩容超过 10 万台云主机，投入的计算资源超 100 万核。疫情停工期间，每周都有数万家企业和政府相干机构应用腾讯会议停工复产，通过腾讯会议开辟了云签约、云投标、云面试、云培训等云上协同场景。

腾讯会议这款云视频会议产品，日沉闷账户数已超 1000 万，成为以后中国最多人应用的视频会议专用利用。目前，腾讯会议国际版也曾经在超过 100 个国家和地区上线，助力寰球战疫。

作为腾讯会议外围数据库，近期腾讯分布式数据库 TDSQL 继续撑持腾讯会议应答快速增长的存储容量和性能需求，为用户提供高速晦涩、稳固牢靠的服务，在安稳应答流量突增，实现让用户无感知的状况下进行疾速无损在线扩容的场景方面提供了最佳实际案例。

一、不停机无损线性程度扩容

面对流量突增场景，保障系统高可用的第一要务是进行零碎扩容，满足业务的性能和容量需要。

回顾腾讯会议数据库面对流量突增的过程，作为腾讯会议的重要零碎根底反对，随着流量的继续暴涨，优化之后 TDSQL 进行了一轮疾速的数据库机器程度扩容实际：

通过 TDSQL 策略丰盛的读写拆散技术，数据库层面疾速响应了持续增长的容量和性能需求。
为了尽可能的将读申请拆散，进一步升高对主节点的影响，TDSQL 通过读写账号拆散、灾备只读实例等措施，将纯只读业务分离出来，进一步升高主节点的压力进步整体的吞吐量。最终，25% 的简单查问依据读写拆散策略发往只读实例，疾速达到升高主节点的负载的成果。
强壮的散布事务能力撑持，继续一直地进行性能优化。
SQLEngine 作为协调节点，无状态，能满足业务层简直无限度的程度扩容需要。
不停机无损线性程度扩容，保障系统高可用、高性能，数据库技术架构如何做到？两头有哪些看不见的坑，有没有通过了理论验证的最佳计划？

数字化转型全局倒退正在提速，流量洪峰渐成常态**，将来，咱们须要怎么的分布式技术架构零碎？

以下咱们一一拆解。

二、程度扩容的背景和挑战

就扩容来说，比拟常见的就是两种形式，一种是垂直扩容，一种是程度扩容。这两种有不同的特点，优缺点其实也非常明显。

程度扩容行将数据从一台机器上拆分到多台机器，通过将一台物理机的申请扩散到多台来实现吞吐量的晋升。垂直扩容是将数据从一台低规格的物理机迁徙到一台高规格的设施，通过物理硬件的晋升实现吞吐量的晋升。

跟垂直扩容比照，分布式程度扩容最大的长处是解决了垂直扩容的瓶颈问题——实践上程度扩容能够进行有限扩容，它能够通过减少机器的形式来动静适应业务的需要。

程度扩容和垂直扩容相比，它能够解决垂直扩容的问题，然而会引入一些其余的问题。因为程度扩容比垂直扩容更加简单，上面咱们剖析下可能遇见的问题，以及介绍 TDSQL 架构设计的解决方案：

第一，零碎通过垂直扩容，其实数据总体还是存在一个节点，一主多备架构中，备机上也存储着所有数据。而程度扩容过程中数据会进行拆分，这里面临的第一个问题是，数据如何进行拆分？因为如果拆分不好，当呈现热点数据时，存储热点数据的独自节点也有可能成为性能的瓶颈。

第二，程度扩容会波及到数据的搬迁、路由的扭转。那么整个过程中是否做到对业务没有感知？或者是对业务的侵入如何尽可能地升高？

第三，扩过程中的诸多步骤，如果其中一步失败了，如何进行回滚？同时，在整个扩容过程中，如何能保障切换过程中数据一致性？

第四，因为扩容后数据拆分到了各个节点，如何能保障扩容后的性能？在整个程度扩容的过程中，不同的架构或者不同的形式，对性能影响都比拟大。

第五，当数据曾经拆分成多份，如何持续保障数据库分布式的个性？在分布式架构里，如何保证数据跨节点过程中的全局的一致性？这个就会波及到分布式事务。

综上思考，程度扩容的长处很显著，它解决了垂直扩容机器的限度。然而它更简单，引入了更多的问题。那么 TDSQL 是如何进行程度扩容，又是如何解决上述问题的呢？

三、TDSQL 程度扩容实际

1. TDSQL 架构
首先看 TDSQL 的架构。TDSQL 简略来说蕴含几局部：

第一局部是 SQL 引擎层：次要是作为接入端，屏蔽整个 TDSQL 后端的数据存储细节。对业务来说，业务拜访的是 SQL 引擎层。

接下来是由多个 Set 组成的数据存储层：分布式数据库中，数据存储在各个节点上，每个 Set 咱们当做一个数据单元，能够依据业务须要来部署一主两备或者一主多备。对于对数据安全性要求更高的业务场景，能够一主三备甚至一主四备。

Scheduler 模块：次要负责整个零碎集群的监控、管制。在零碎进行扩容或者主备切换时，Scheduler 模块相当于整个零碎的大脑，来对系统进行管制。而对业务来说是无感知的，业务只需关注 SQL 引擎层，不须要关注 Scheduler，不须要关注数据是怎么跨节点，怎么分成多少个节点等。

2. TDSQL 程度扩容过程：一键扩容
整个扩容流程总结起来大略是：一开始数据都放在一个 Set 上，也就是在一个节点外面。扩容则会把数据扩容到多个节点上。比方有 256 个 Set，就会扩容到 256 台机器上。整个扩容过程有几个要点：

一开始尽管数据是在一个节点上，在一台机器上，然而其实数据曾经进行了拆分。
程度扩容，简略来说是将这些分片迁徙到其余的 Set 上，也就是其余的节点机器上，这样就能够实现减少机器来提供零碎性能。
总结来说，数据一开始曾经切分好了，扩容过程相当于把分片迁到新的节点，整个扩容过程中，节点数是减少的，能够从 1 扩到 2 扩到 4，甚至扩到最初能够到 256，然而分片数是不变的。一开始 256 个分片在一个节点上，扩成两个节点的话，有可能是每 128 个分片在一个节点上；扩到最初，能够扩到 256 个节点上，数据在 256 台机器，每台机器负责其中的一个分片。因而整个扩容简略来说就是搬迁分片。

无论是在公有云或私有云上，TDSQL 提供了一个对立的前台页面，不便用户应用治理整个数据库系统。

四、TDSQL 程度扩容背地的设计原理

为了保障分布式数据库系统的数据强一致性、疾速线性程度扩容、高性能、高可用等，解决前文提到的问题，TDSQL 架构计划进行了相应的设计。事实上，这些问题不论在哪个零碎做程度扩容，都是须要解决的。

1. 设计原理：分区键抉择如何兼顾兼容性与性能
程度扩容第一个问题是数据如何进行拆分。数据拆分是第一步，将影响后续整个应用过程。

在 TDSQL 中，数据拆分的逻辑放到一个创立表的语法外面，须要业务去指定“shardkey 等于某个字段”——业务在设计表构造时须要抉择一个字段作为分区键，TDSQL 会依据这个分区键进行数据拆分，而拜访会依据分区键进行数据聚合。

咱们是心愿业务在设计表构造的时候可能参加进来，指定一个字段作为 shardkey。这样一来，兼容性与性能都能做到很好的均衡。

TDSQL 也能够做到用户创立表的时候不指定 shardkey，由零碎底层随机抉择一个键进行数据拆分，但这个会影响后续的应用效率，比方不能特地好地施展分布式数据库的使用性能。因而，业务层如果在设计表构造时能有大量参加，能够带来十分大的性能劣势，让兼容性和性能失去均衡。

除此之外，如果由业务来抉择 shardkey——分区键，在业务设计表构造的时候，咱们能够看到多个表，能够抉择相干的那一列作为 shardkey，这样能够保证数据拆分时，相干的数据是放在同一个节点上的，这样能够防止很多分布式状况下的跨节点的数据交互。

2. 设计原理：扩容中的高可用和高可靠性

扩容流程比较复杂，那么整个扩容过程是否保障高可用或者高可靠性，以及对业务无感知？TDSQL 是怎么做的呢？

（1）数据同步
第一步是数据同步阶段。假如咱们当初有两个 Set，而后咱们发现其中一个 Set 当初的磁盘容量曾经比拟危险了，比方可能达到 80% 以上了，这个时候要对它进行扩容。

咱们首先会新建一个实例，通过拷贝镜像、新建实例、新建同步关系。建设同步的过程对业务无感知，而且这个过程是实时同步。

（2）数据校验
第二阶段，则是继续地追平数据，同时继续进行数据校验。这个过程可能会继续一段时间，对于两个同步之间的延时差有限靠近时——比方咱们定一个 5 秒的阈值，当咱们发现曾经追到 5 秒之内时，这个时候咱们会进入第三个阶段——路由更新阶段。

（3）路由更新
路由更新阶段当中，首先咱们会解冻写申请，这个时候如果业务有写过来的话，咱们会拒掉，让业务两秒后重试——这个时候对业务其实是有秒级的影响。然而这个工夫会十分短。

解冻写申请之后，第三个实例同步的时候很快就会发现数据全副追上来，并且校验也没问题，这个时候咱们会批改路由，同时进行相干原子操作，在底层做到存储层分区屏蔽，这样就能保障 SQL 接入层在路由来不及更新的时数据也不会写错。因为底层做了扭转，分区曾经屏蔽了。这样就能够保证数据的一致性。

路由一旦更新好当前，第三个 Set 就能够接管用户的申请——到了这里，因为第一个 Set 和第三个 Set 曾经建设了同步，所以它们两个是领有全量数据的。

（4）删除冗余数据
最初一步则须要把这些冗余数据删掉。删冗余数据用的是提早删除，保障删除过程中能够缓缓删，也不会造成比拟大的 IO 稳定，影响现网的业务。

整个删除过程中，咱们做了分区屏蔽，同时会在 SQL 引擎层做 SQL 的改写，这样就能保障：咱们在底层尽管有冗余数据，但用户来查的时候即便是一个全扫描，咱们也能保障不会多一些数据。

能够看到整个扩容流程，数据同步，还有校验和删除冗余这几个阶段，工夫消耗相对来说会比拟长，因为要建同步的话，如果数据量比拟大，整个拷贝镜像或者是追 binlog 这段时间绝对比拟长。

然而这几个阶段对业务其实没有任何影响，业务基本就没感知到当初新加了一个同步关系。那么如果在建设同步关系时发现有问题，或者新建备机时出问题了，也齐全能够再换一个备机，或者是通过重试，这个对业务没有影响。

路由更新阶段，实践上对业务写申请难以避免会造成秒级的影响，但咱们会将这个影响工夫窗口期管制在十分短，因为自身解冻写申请是须要保障同步曾经在 5 秒之内这样一个比拟小的阈值，同步到这个阶段当前，咱们能力发动路由更新操作。

同时，咱们对存储层做了分区屏蔽来保障多个模块之间，如果有更新不同时也不会有数据错乱的问题。这是一个咱们如何保障扩容中的高可用跟高可靠性的，整个扩容对业务影响十分小的原理过程。

3. 设计原理：分布式事务

方才讲的是扩容阶段大略的流程，以及 TDSQL 是如何解决问题的。接下来咱们再看扩容实现当前，如何解决方才说的程度扩容当前带来的问题。

首先是分布式事务：原子性、去中心化、性能线性增长。

零碎原本只有一个节点，扩容当前，数据是跨节点了，如何保证数据的原子性？咱们基于两阶段的提交，实现了分布式事务。对业务屏蔽了整个解决逻辑背地的复杂性，对业务来说应用分布式数据库就跟应用单机 MySQL 一样。

如果业务这条 SQL 只拜访一个节点，那用一般的事务就能够；如果发现用户的一条 SQL 或者一个事务操作了多个节点，咱们会用两阶段提交。到最初会通过记日志来保障整个分布式事务的原子性。

同时咱们对整个分布式事务在实现过程中做到齐全去中心化，能够通过多个 SQL 来做 TM，性能也可实现线性增长。除此之外，TDSQL 也做了大量的各种各样的异样验证机制，有十分强壮的异样解决和全局的试错机制，并且通过了 TPCC 的规范验证。

4. 设计原理：如何实现扩容中性能线性增长
对于程度扩容来说，数据拆分到多个节点后次要带来两个问题：一个是事务原子性的问题，能够通过分布式事务来解决；此外还带来了性能方面的问题。

垂直扩容中个别是通过更换更好的 CPU 等办法来实现性能线性减少。对于程度扩容，因为数据拆分到多个节点上，如何能力很好地利用到拆分上来的各个节点，进行并行计算，真正把程度分布式数据库的劣势施展进去，须要大量的操作、大量的优化措施。TDSQL 做了这样一些优化措施：

一是相干数据存在同一个节点上。建表构造的时候，咱们心愿业务能参加进来一部分，在设计表构造的时候指定相干的一些键作为 shardkey，这样咱们就能保障后端的相干数据是在一个节点上的。如果对这些数据进行联结查问就不须要跨节点。

同样，咱们通过并行计算、流式聚合来实现性能晋升——咱们把 SQL 拆分散发到各个后盾的节点，而后通过每个节点并行计算，计算好当前再通过 SQL 引擎来做二次聚合，而后返回给用户。

为了缩小数据的拉取，咱们会做一些下推的查问——把更多的条件下推到 DB 上。此外咱们也做了数据冗余，通过数据冗余保障尽量减少跨节点的数据交互。

咱们简略看一个聚合——TDSQL 是如何做到程度扩容当前，对业务根本无感知，应用形式跟应用单机 MySQL 一样的。

对业务来说，假如有 7 条数据，业务不必管这个表具体数据是存在一个节点还是多个节点，只须要插 7 条数据。零碎会依据传过来的 SQL 进行语法解析，并主动把这条数据进行改写。7 条数据，零碎会依据分区键计算，发现这 4 个要发到第一个节点，另外 3 个发到第二个节点，而后进行改写，改写好之后插入这些数据。对用户来说，就是执行了这么一条，然而跨节点了，咱们这边会用到两阶段提交，从而变成多条 SQL，进而保障一旦有问题两边会同时回滚。

数据插录完当前，用户如果要做一些查问——事实上用户不晓得数据是拆分的，对他来说就是一个残缺的表，他用相似聚合函数等进行查问。同样，这条 SQL 也会进行改写，零碎会把这条 SQL 发到两个节点上，同时加一些均匀函数，进行相应的转换。到了各个节点，零碎会先做数据聚合，到这边再一次做聚合。

减少这个步骤的益处是，这边过去的话，咱们能够通过做聚合——相当于在这里不须要缓存太多的数据，并且做到流式计算，避免出现一次性耗费太多内存的状况。

以上是 TDSQL 程度扩容方案设计原理以及实际过程的介绍。

结语
除了腾讯会议，疫情期间，TDSQL 还基于腾讯云疾速反对了多地区衰弱码、市政防控平台小程序等高并发、筹备工夫短的我的项目利用顺利上线、稳固运行，服务民众数亿，日均调用数十亿次。

根底技术的积攒让咱们明天领有顺利应答所有突发变动的能力，将来基于新型业务状态，咱们的底层根底技术也将一直迭代演进，开启下一个数字化时代。