admin 管理员组

文章数量: 887031


2024年2月22日发(作者:textarea值改变触发事件)

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也好,用户也好,完成一些个性化的丰富的需求。

架构模块及其特性

首先用户的请求通过负载均衡发往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引擎。


本文标签: 模块 数据 管理