TDSQL 核心架构

TDSQL 的架构以及模块划分。通过这一章节的了解，我们更能切入 TDSQL 的技术细节，它为什么要这样设计，这样设计有什么好处，如何通过这样的架构和设计实现高可用、线性扩展等能力。

TDSQL 系统总览

1.1 资源池

这张图从下往上看，首先最底层是资源池，属于 IaaS 层服务，可以是物理机，也可以是虚拟机，只要是给 TDSQL 添加机器就好，TDSQL 是在一个机器的资源池上实现了数据库实例的管理。当然，这里推荐的还是物理机，如果增加一层虚拟机服务，无疑在稳定性和性能方面都会引入一些隐患。

1.2 存储节点

**从资源池再往上是存储节点。存储节点要强调的是 TDSQL 的两种存储形态，一种是 Noshard 数据库，一种是分布式数据库（也叫 Shard 版 TDSQL）。**简单来说，Noshard 就是一个单机版的 TDSQL，在 MySQL 的基础上做了一系列的改造和改良，让它支持 TDSQL 的一系列特性，包括高可用，数据强一致、7×24 小时自动故障切换等。第二种是分布式数据库，具备水平伸缩能力。所以 TDSQL 对外其实呈现了两种形态，呈现一种非分布式形态，一种是分布式的形态。至于这两种形态的区别，或者说什么场景更适合于哪种数据库，后面我们有专门的章节去分析。

1.3 计算节点

再看计算节点。**计算节点就是 TDSQL 的计算引擎，做到了计算层和存储层相分离。**计算层主要是做一些 SQL 方面的处理，比如词法解、语法解析、SQL 改写等。如果是分布式数据库形态，还要做分布式事务相关的协调，所以我们看到计算层不存储数据，只运行 SQL 方面的实时计算，所以它更偏 CPU 密集型。此外，TDSQL 计算节点还具备 OLAP 的能力，对一些复杂的计算可以进行算法上的优化——什么时候该下推到存储引擎层，什么时候需要在计算层做汇总等，这是计算节点需要做的事情。

1.4 赤兔运营管理平台

再往上，是赤兔运营管理平台，如果说把下面这一套东西比作一个黑盒，我们希望有一个用户界面操纵这个黑盒，这个界面就是赤兔运营管理平台。通过这个平台，DBA 可以操纵 TDSQL 后台黑盒，所以相当于是一套 WEB 管理系统。让所有 DBA 的操作都可以在用户界面上完成，而不需要登陆到后台，不需要关心计算节点是哪个，存储节点是哪个，或者怎么样管理它，要加一些节点或者减一些节点，或者把这个节点从哪里要迁到哪里……这些都可以通过界面化完成。DBA 操作界面不容易出错，但如果登陆到后台很容易一个误操作，不小心把机器重启了，就可能会造成一定的影响。

1.5 “扁鹊”智能 DBA 平台

有了赤兔之外，为什么还有一个“扁鹊”智能 DBA 平台呢？可能正常情况下，我们机器是好的，但是，机器如果发生了故障，或者说哪天磁盘有坏块了，或者是 IO 性能越来越差……SSD 其实有一个衰老的过程，到了后期的话，吞吐量和 IOPS 可能会有一定下降，导致数据库的响应速度变慢。这种情况如果 DBA 要排查，得先去看到是哪一个实例、涉及到哪一台机器、这个机器有什么问题、检测机器的健康状态……这些都是机械性的工作，有了扁鹊智能管理平台，当出现故障的时候就可以自动分析故障的原因，举个例子，可以找出是因为什么导致 SQL 变慢了，或者又是因为什么原因发生了主备切换，突然 IO 异常了或者其他什么原因导致机器故障。

此外，扁鹊智能 DBA 平台还有一个智能诊断系统，可以定期由 DBA 发起对实例进行的诊断。比如有些数据库实例，CPU 常年跑得很高，其实是一些比较差的 SQL 导致的。这个时候扁鹊智能 DBA 系统，可以很方便地到用户实例上做巡检，得到一个健康状况图，并对它进行打分，发现这个实例比如他的 CPU 超用了，需要扩容，但是没有扩容，就会减分；然后其他表的索引没有建好，要减分……以此生成一个诊断报告。所以，有了扁鹊，再加上赤兔运营管理平台，DBA 的工作其实是非常轻松的，可能每天只需要点几下按纽，然后就解决了一系列的麻烦，包括高可用，性能分析，锁分析等，完全把 DBA 从繁杂的工作中解放出来。

此外，我们看到这里其实还有几个小的模块。调度系统，调度系统主要是负责整体的资源调度，比如说数据库实例的增加删除、过期作废，还有一些容量的调度，即扩容、缩容，还有一些多租户的管理。也就是说这是整个管理台的调度器。

另外还有一个备份系统，这个是冷备中心，后面有一个专门的章节去讲，这里就不再赘述。此外，我们还提供了一些服务模块作为辅助，比如审计，还有数据库之间的迁移服务——我们 TDSQL 怎么能够帮助异地数据库迁进来，或者从 TDSQL 再迁出。此外，还包括数据校验、数据订阅、SQL 防火墙、注入检测等安全方面的模块，以及一个辅助模块——帮助我们的 DBA 也好，用户也好，完成一些个性化的丰富的需求。

2.TDSQL 架构模块及其特性

**首先用户的请求通过负载均衡发往 SQL 引擎。**然后，SQL 引擎作为计算接入层，根据这个 SQL 的要求从后端的存储节点去取数据。当然，无论是 SQL 引擎还是后端的数据库实例都存在一个元数据来管理调度。举个例子，计算引擎需要拿到一个路由，路由告诉 SQL 引擎，这个 SQL 该发往哪一个后端的数据节点，到底是该发往主节点还是发往备节点。所以我们引入了 ZK（Zookeeper）来储存类似于路由这类元数据信息。当然 ZK 只是静态的存储元数据，维护和管理这些元数据信息，还需要有一套调度以及接口组件，这里是 OSS、Manager/Schedule。所以我们这张图可以看到是 TDSQL 整体来说就分为三部分：管理节点、计算节点和存储节点。当然这里还有一个辅助模块，帮助完成一些个性化需求的，比如备份、消息队列，数据迁移工具等。另外，这里的负载均衡其实不是必需的，用户可以选用自身的硬件负载，也可以用 LVS 软负载，这个负载均衡根据实际的用户场景可自定义。

了解了整体架构以后，我们继续再看一下每个节点的特性是什么、对机器的依赖程度如何，要求机器有哪些特性，等等。

2.1 管理模块：轻松通过 web 界面管理整个数据库后台

首先，我们要看的是管理模块。作为一个集群只搭建一套的管理模块，一般可以复用一组机器。同时，管理模块对机器的要求相对来说比较低，比如资源紧张的时候，我们用虚拟机就可以代替。在我们内部，一套管理模块承载最大的管理单集群近上万实例。

**管理模块包含前文说的几个关键模块：Zookeeper(ZK)、Scheduler、Manager、OSS 和监控采集程序、赤兔管理控制台。**那么它们是怎么联合工作的呢？首先，DBA 用户在赤兔管理台——这一套 WEB 前台发起一个操作——点了一个按纽，这个按纽可能是对实例进行扩容，这个按纽会把这个 https 的请求转移到 OSS 模块，这个 OSS 模块有点像 web 服务器，它能接收 web 请求，但是它可以把这个转发到 ZK。所以，OSS 模块就是一个前端到后台的桥梁，有了 OSS 模块，整个后台的工作模块都可以跟前台、跟 web 界面绑定在一起。

好，捕捉到这个请求之后，在 ZK 上创建一个任务节点，这个任务节点被调度模块捕获，捕获之后就处理任务。处理完任务，再把它的处理结果返回到 ZK 上。ZK 上的任务被 OSS 捕获，最后也是 https 的请求，去查询这个任务，最后得到一个结果，返回给前端。

这是一个纯异步的过程，但是有了这套管理模块，让我们可以轻松的通过 web 界面去管理整个 TDSQL 的后台。当然，这整个过程都有一个监控采集模块去采集，对整个流程的审计及状态进行获取。

2.2 DB 模块：数据库无损升级

DB 模块，即数据节点，数据存取服务属于 IO 密集型的服务，因此，数据节点也是我们的存储节点，它对 IO 的要求比较高，一般建议配置 SSD 硬盘，最好是 PCI-E 的 SSD。因为对数据库服务来说，CPU 再高，如果 IO 跟不上，仍然是小马拉大车。比如只有 1 千的 IOPS，CPU 根本就跑不起来，用不起来。所以这里一般建议至少 IPS 要达到 1 万以上。

我们再看一下 SET 的概念。**SET 就是数据库实例，一个 SET 包含数据库的——比如我们默认要求的是一主两备，一个 Master 节点和两个 Slave 节点。当然在 DB 节点上有一个 Agent 的模块。**MySQL 在执行中，我们要监控它的行为，以及进行操作。如果把这些东西做到 MySQL 里面为什么不可以呢？这其实存在一个问题，如果对数据节点进行升级，可能就要涉及到重启，一旦重启就影响用户的业务，影响服务。这个时候我们就考虑，在它上面加一个模块 Agent，它来完成对所有集群对 MySQL 的操作，并且上报 MySQL 的状态。有了它之后，对 TDSQL 数据节点的大部分升级，都会转变为对 Agent 的升级，而升级 Agent，对业务没有任何影响，这就实现了无损升级。相比于 Agent 我们对数据节点 MySQL 不会频繁升级，一般情况下一年、半年都不会动它。这是我们 DB 模块，也是存储节点。

2.3 SQL 引擎模块：分布式复杂 SQL 处理

**接下来再看另外一个比较重要的模块：SQL 引擎模块。**SQL 引擎处于计算层的位置，本身属于 CPU 密集型，所以我们在选机型上尽量要求 CPU 高一些。其次是内存，作为计算接入层，它要管理链接，如果是大量的短链接或者长链接，非常占内存，所以它对 CPU 和内存的要求比较高。此外，它本身不存储数据，也没有主备之分，所以对硬盘没有太大要求。

我们看一下 SQL 引擎的特性。SQL 引擎首先还是从 ZK 上拉取到元数据，作为 SQL 引擎，包括权限校验、读写分离，以及统计信息、协议模拟等相关的操作。

可能有些人会问，其实这个 SQL 引擎岂不是一种中间件？其实并不是这样，SQL 引擎如果是一个中间件，它都可以脱离 MySQL。但是我们这个 SQL 引擎，需要做词法、语法分析，以及作为查询引擎等工作。而且在分布式的场景下，SQL 引擎复杂的功能性就会凸显，比如要处理分布式事物，还要维护全局自增字段，保证多个数据、多个存储节点共享一个保证全局自增的序列；如果是分布式的话，要限制一些语法，包括词法和语法的解析；还有在一些复杂计算上，它还要做一些 SQL 下推，以及最后数据的聚合。所以 SQL 引擎还是一个相对来说比较复杂的模块，作为计算层，并不是一个简单的中间件那么简单。这就是一个 SQL 引擎。