TDSQL（MySQL）架构原理总结

TDSQL（MySQL）架构原理总结

一、思维导图


二、核心架构

1、架构概述

TDSQL的核心架构：


2、TDSQL核心模块

模块	作用
DB	DB就是实际用于存储业务数的MySQL实例
keeper	是整个集群的资源管理和调度中心，keeper模块包括manager和scheduler模块
Gateway	负责SQL的解析与计算，以及和Zookeeper进行交互

3、DB模块简介

1）Set模型

在上图集群的架构中，可以看到DB是以Set为基本单位进行部署的，每一个Set包含3个MySQL的实例，分别是一主两备，TDSQL的所有高可用机制都是建立在Set之内实现的

2）Agent简介

在每一个MySQL的实例上都有一个Agent，可以将它看做一个旁路的模块，是集群中的各个节点之间进行信息交互的桥梁，主要功能如下：

• 监控MySQL的实例是否能够正常的运行，及时上报实例异常的信息，便于Scheduler模块判断是否需要进行容灾切换，同时会监测是否有容灾切换的任务
• 监测MySQL实例的资源利用率、各个表的请求量和数据量，并上报到Zookeeper，Scheduler模块根据资源的使用情况判断是否需要进行扩容或者缩容；同时会监测是否有扩容或缩容的任务下发
• 监测主从复制和数据同步的情况，定期上报主备复制的延时和延迟的事物数，如果发生了主备切换会自动向新主机重建主备
• 迁移、配置文件修改、表一致性校验、binlog\镜像备份等任务的检测

3）功能原理简介：

a、心跳监测

Agent会尝试通过Socket连接DB、写DB和读取DB，如果这三个操作中有一个不成功即上报存活状态异常，Scheduler会根据异常信息进行容灾切换，Agent在Zookeeper中存储的节点类型是临时节点，当Agent出现异常临时节点会消失，此时Scheduler会检测到对应的异常并处理。Scheduler控制整个切换的流程。

b、主备切换

在TDSQL数据库中，强一致性是必须要保证的，就是说，可以拒绝提供服务，但是不能提供错误的服务，主备切换的过程是需要保证数据的一致性的，过程如下

1. Set中的主机降为备机，Agent kill掉当前所有的会话，将实例设置为只读状态
2. Agent停止参与选举的线程，加载中继日志
3. 两个备机向Scheduler上报最新的Binlog点
4. Scheduler将Binlog最大的节点设置为主机
5. Set内转换主备的关系，网关更新路由

c、主备同步

主备同步需要依赖GTID（Global transaction identifiers，事物ID），同步的过程

• 备机和主机建立同步时，备机将自己的gtidlist发送给主机，主机根据gtidlist扫描自己的Binlog文件，发现备机需要同步的位置；如果找不到同步的位置点，会通知拉取镜像，拉取加载完成后，再根据binlog同步点和主机建立同步连接

d、数据备份

方式	方法
物理备份	通过xtrabackup备份物理文件，并且将其压缩至HDFS
逻辑备份	每个库，每个表可以独立备份至HDFS，恢复即可恢复；mydumper
Binlog备份	实时备份Binlog到HDFS

4、Scheduler模块简介

a、功能简介

Scheduler是整个集群的管理调度中心，相当于整个集群的大脑，调度集群系统帮助DBA货值数据库用户自动调度和运行各种类型的操作，比如，数据监控、收集监控生成各种报表、主备切换、扩缩容。

• 分析Agent上报上来的心跳信息，决策是否进行主备切换，控制切换流程
• Set发生故障时进行扩容缩容
• 统一下发和调度所有的DDL操作
• Scheduler本身的单点故障的问题

b、功能原理简介

自身选举机制流程：

1. 主机和备机Scheduler启动，都会在zk上注册一个临时节点，节点根据GJID生成
2. 获取当前集群下的所有节点
3. 查找最小node节点机器，根据节点内容获取gjid，再根据获取对应的ip地址
4. 判断最小node节点对应的ip和本机ip是否相同，相同则为主机，否则为备机

高一致性容灾

Set中的主机出现故障的时候，切换主机的流程如下：

1. Scheduler监测到主机故障后，选择备机1作为新主机，并且通知它为新主机
2. 备机1重放所有的中继log
3. 备机2调整master指向新主机（原来的备机1）
4. 备机1升级完成，成为新主机，并且上报Scheduler
5. Scheduler通知网关修改指向的主机路由

数据的迁移

1. 原实例Agent将备份镜像复制至目标机，目标实例Agent加载镜像
2. 目标实例Agent根据日志点，创建至源主机的主备关系
3. Scheduler锁定所有的分区，只提供读操作，直至日志追平
4. Scheduler通知网关修改路由至目标Set
5. Scheduler下发删除旧数据的分区的指令，源实例Agent删除旧数据

5、manager模块简介

manager是机器资源管理模块，也是任务执行者，它是和Scheduler一起运行的。manager数以Zookeeper为数据仓库的，启动时从Zookeeper中加载资源信息，对齐进行处理后及时协会Zookeeper节点存储。manager的主要功能就是机器管理、实例管理、网关管理、集群管理和用户管理


1、网关模块简介

网关主要基于MySQL Proxy开发，可以将其看做数据库访问的中间件，主要在客户端和后端的存储之间完成SQL解析和计算、用户鉴权、路由分配和读写分离等功能

功能	解释
用户鉴权	建立连接时负责进行用户名和密码的校验，向后端连接时透传客户端ip
SQL解析	proxy使用原生的MySQL和词法对客户端发来的SQL语句进行解析和重组，再向DB发送真正的SQL语句
数据聚合	Proxy支持聚合多个后端的数据，对常见的操作均可，如count、distinct、sum、avg、max、min、order by和group by
路由选择	Proxy会实时监测路由信息，根据sk，计算hash，决定SQL发向那个Set；而且当主备切换的时候，proxy能够监测到实时变化
读写分离	一般情况下每个Set中的主机是可读可写的，备机是只读的，所以Proxy层即系出SQl请求是select类的会转发至备机，备机选择的时候也会考虑延迟和地理位置等因素
日志信息	sys：Proxy处理每条SQL语句的详细日志<br />inter：接口日志，对应客户单端的每条SQl<br />sql：对应发向后端的每条sql，一个客户端所发的SQl需要Proxy向后端发出多条sql<br />slow：慢查询日志

2、其他配套组件

组件
冷备系统	基于HDFS或者其他的分布式文件系统，自动备份，一键恢复
消息队列	基于kafaka定制的binlog订阅服务，还有SQl审计和多远同步等服务
资源管理	基于Group对TSQL的实例进行编排，提高机器的资源利用率
OSS	对TDSQL的所有操作，比如扩容，备份，恢复，手动切换，申请，修改和删除实例等操作均提供统一的HTTP接口；OSS的流程交互如下所示
数据采集	TDSQL所有的内部运营状态或者数据，都能实时地进行采集，业务可以基于这些数据作分析或者构建运营平台监控系统
管理平台	基于以上模块，TDSQL有自带运营管理平台
审计模块	审计模块通过对用户访问数据库行为的日志才分析，用来帮助用户事后生成合规的报告事故追根溯源，同时加强内外部数据库网络行为记录，增强安全性


3、TDSQL关键特性

对于一个存储系统来说比较关注的是其可用性和易用性，可用性指的是当系统出现故障时，如何处理请求或者当系统面对大量的并发请求时能否正常响应；易用性是指该系统提供给业务开发员的API接口是否足够方便，给运维人员提供的接口是否足够丰富。TDSQL在这两个方面做的足够丰富。

a、数据一致性

TDSQL基于MySQl的binlog的严格有序性以及强同步复制机制，结合Raft协议的一些设计思想保证了数据的一致性，Raft协议的核心就是同步机制和选举机制。

基于Set机制的同步机制：TDSQl所有的高可用机制均是在Set之内实现，每个Set之内多个数据节点，主备之间可以是基于Raft协议的强同步复制机制

Leader选举：MySQL节点本身是无法参与选举的，在TDSQL是通过SCheduler模块来负责选举的。如果主机发生故障，Scheduler会从两个备机中，选择一个数据较新的备（MySQL的Binlog日志是严格有序的，所以那个同步主机的binlog的偏移量最大，谁的数据就最新，对应的也会被选为主机

b、高可用性

通过多副本冗余和故障的自动切换机制，解决了单点问题，确保在单机、单IDC甚至整个城市灾难时，服务能够持续可用

c、强同步机制

TDSQL的强同步机制基于MySQL半同步复制，并进行了优化，对于进入集群的每笔更新操作，都将发到对应Set的主机上，主机会将Binlog发往两个备机，且收到其中任意一个备机ACK后（仅仅是备机收到了Binlog，但可能还没有执行该Binlog），然后才本地提交，并返回给客户端应答，这就能确保数据零丢失。但是强同步机制在一定程度上会影响系统的性能

d、自动扩容

TDSQL引入集群机制，实现了自动的容量伸缩，确保在业务访问量飙升的时候，整个集群可以自动扩容提供对外访问，这种扩容应该是动摇的，对业务应该完全透明，无需业务停机

TDSQL有两个分支版本，一个是NO-Sharding(非分布式)版本，一个是Group-Sharding(分布式）版本，NS版本不支持自动扩容(一个Set)，GS版本支持自动扩容(多个Set)，但是该版本不支持跨节点事物和join

e、分布式事务

分布式事务本质上还是为了解决在分布式系统中数据一致性的问题。对于分布式数据库，存在存储副本以及数据库本身的分库分表等问题使得一个事物中存在着对不同节点的操作，这就是典型的分布式事务。TDSQL基于MySQL的XA实现了分布式事务机制，在性能损失较低的情况下保证了系统中数据的一致性

d、完整的自动化运营体系和完善的配套设施

TDSQL的整个集群架构中包括自动化运营发布平台、机器资源自动管理平台、只能监控平台和数据库智能诊断平台(扁鹊).TDSQL提供Binlog订阅，冷备系统和多源同步系统

6、常见的部署方案

1、同城单中心的架构

这种架构一般用作测试、异地灾备的机房或者业务不能容忍跨数据中心访问带来的网络延迟。每个数据库实例采用三个节点的模式，主备机需要跨不同的机架，主机宕掉之后，TDSQL会在40s左右完成自动地切换，业务基本无感知。

2、同城三中心的架构

每个数据库实例采用三个节点的模式部署，分布在3个IDC。业务系统支持多活模式部署每个IDC内的业务系统访问本IDC内LVS/TGW对应的虚拟IP，由其后端的Proxy模块将请求路由到正确的主备数据库节点。对于读写分离的请求优先访问本IDC的备机，任何一个数据库节点宕掉时，TDSQL会在40秒左右完成自动切换。

3、两地三中心结构

这种架构是同城两个中心+异地的中心，可以提供非常好的可用性和一致性，是TDSQL主要推荐的部署模式。每个数据库实例采用4-6个节点的模式，分布在3个IDC，业务系统支持多活模式的部署。