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 也好，用户也好，实现一些个性化的丰盛的需要。

以上是 TDSQL 零碎总览。

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 引擎。