| 作者：杨壮壮 ，腾讯PCG运营开发工程师 ，目前主要从事 MDB（MySQL 云管平台）的后台开发与技术运营的工作，是一个做开发的DBA。熟悉腾讯自研数据库TDSQL的架构原理、集群管理维护、内核SQL优化等。MDB团队承载着整个PCG 关系型数据库的管理与运维工作，支撑着腾讯视频、看点等业务稳定运行。
1
Part1 前言
1
Part2 TDSQL 核心架构
TDSQL主要由三大核心模块组成，分别是：
（1）DB：DB就是实际用于存储业务数据的MySQL实例；
（2）keeper：是整个集群的资源管理和调度中心，keeper模块包括manager模块和scheduler模块；
（3）Gateway：负责SQL的解析与计算，以及和Zookeeper进行交互。
2、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会检测到对应的异常。
b、主备切换
一个分布式系统系统只能满足CAP理论的中的两个特性，在TDSQL数据库中，强一致性是必须要保证的，所有需要牺牲掉一部分的可用性，即可以拒绝提供服务，但是不能提供错误的服务，主备切换的过程是需要保证数据的一致性的，具体的过程如下：
• Set中的主机降级为备机，Agent kill 掉当前所有的会话，将实例设置为只读状态；
• Agent停止参与选举备机的线程，加载中继日志；
• 两个备机向Scheduler上报最新的Binlog点；
• Scheduler将Binlog最大的节点设置为主机；
• Set内转换主备关系，网关更新路由。
c、主备同步
主备同步需要依赖于GTID（Global transaction identifiers，事务ID），同步的过程：
• 备机和主机建立同步时，备机将自己的gtidlist发送给主机，主机根据gtidlist扫描自己的Binlog文件，发现备机需要同步的位置；如果找不到同步的位置点，会通知备机拉取镜像，拉取并加载完成后，再根据binlog同步点和主机建立同步连接。
d、数据备份
• 物理备份：通过xtrabackup备份物理文件 ，并且将其压缩至HDFS
• 逻辑备份：每个库，每个表可以独立备份至HDFS，恢复时可单独恢复
• Binlog备份：实时备份Binlog到HDFS
3、Scheduler模块简介
Scheduler是整个集群的管理调度中心，相当于整个集群的大脑
（1）Scheduler整体结构：
（2）Scheduler功能简介
在介绍Agent模块的功能原理时，就已经提到了当Set内发生故障要进行容灾切换或者需要进行扩容时，这些操作都是有Scheduler来完成的，所以对于这两方面的功能就不再阐述了
• 管理Set的创建和删除；
• 统一下发和调度所有的DDL操作；
• Scheduler本身的单点故障的问题。
（3）功能原理简介
a、自身选举机制
Scheduler自身的选举流程如下：
• 主机和备机scheduler启动，都会在在zk上注册一个临时节点，节点根据GJID生成；
• 获取当前集群下的所有节点；
• 查找最小node节点机器，根据节点内容获取gjid，再根据gjid获取对应的IP地址；
• 判断最小node节点对应的IP和本机IP是否相同，相同则为主机，否则为备机。
b、高一致性容灾
Set中的主机出现故障的时候，切换主机的流程如下：
• scheduler监测到主机故障后，选择备机1作为新主机，并且通知它为新主机；
• 备机1重放所有的中继log；
• 备机2调整master指向新主机（原来的备机1）；
• 备机1升级完成，成为新主机，并且上报scheduler；
• scheduler通知网关修改指向的主机路由。
c、数据的迁移
• 原实例Agent 将备份镜像复制至目标机，目标实例Agent加载镜像；
• 目标实例Agent根据日志点，创建至源主机的主备关系；
• Scheduler锁定所有的分区，只提供读操作，直至日志追平；
• Scheduler通知网关修改路由至目标Set；
• Scheduler下发删除旧数据分区的指令，源实例Agent删除旧数据。
4、manager模块简介
manager是机器资源管理模块，也是任务执行者，它是和scheduler一起运行的。manager是以Zookeeper为数据仓库的，启动时从Zookeeper中加载资源信息，对其进行处理后及时写回Zookeeper节点存储。manager的主要功能就是机器管理、实例管理、网关管理、集群管理和用户管理。
manager处理任务流图如下：
5、网关模块简介
网关主要基于MySQL Proxy开发，可以将其看作数据库访问的中间件，主要在客户端和后端的存储之间完成SQL解析和计算、用户鉴权、路由分配和读写分离等功能，具体如下：
a、用户鉴权
建立连接时负责进行用户名和密码的校验，向后端连接时透传客户端的IP。
b、SQL解析
proxy使用原生的MySQL语法和词法对客户端发来的SQL语句进行解析和重组，再向DB发送真正的SQL语句。
c、数据聚合
Proxy支持聚合多个后端的数据，对常见的操作的操作均可，如count、distinct、sum、avg、max、min、order by和group by。
d、路由选择
Proxy会实时监测路由信息，根据sk，计算hash，决定SQL发向那个Set；而且当主备切换的时候，proxy能够实时监测到变化。
e、读写分离
一般情况下每个Set中的主机是可读可写的，备机是只读的，所以Proxy层解析出SQL请求是读请求的时候，会将其发向备机，备机选择的时候也会考虑延迟和地位位置等因素
f、日志信息
Proxy主要提供四种日志：
• sys：Proxy 处理每条SQL语句的详细日志；
• inter：接口日志，对应客户端的每条SQL；
• sql：对应发向后端的每条sql，一个客户端所发的SQL需要Proxy向后端发出多条sql；
• slow：慢查询日志。
1
Part3 TDSQL 配套周边系统
1、冷备系统
基于HDFS或者其他的分布式文件系统，自动备份，一键恢复。
2、消息队列
基于Kafka定制的Binlog订阅服务，还有SQL审计和多源同步等服务。
3、资源管理
基于CGroup对TDSQL的实例进行编排，提高机器的资源利用率。
4、OSS
对TDSQL的所有操作，比如扩容、备份、恢复、手动切换、申请，修改和删除实例等操作均提供统一的HTTP接口；OSS的流程交互如下所示：
5、数据采集
TDSQL所有的内部运营状态或者数据，都能实时地进行采集，业务可以基于这些数据做分析或者构建运营平台监控系统。
6、监控平台
业务可以基于数据采集模块采集到所有的数据，对接自建的监控系统，也可以直接使用TDSQL自带的监控系统。
7、管理平台
基于以上模块，TDSQL有自带运营管理平台。
8、审计模块
审计模块通过对用户访问数据库行为的日志采集及分析，用来帮助用户事后生成合规的报告事故追根溯源，同时加强内外部数据库网络行为记录，增强安全性。
1
Part4 TDSQL 关键特性
对于一个存储系统来说比较关注的是其可用性和易用性，可用性指的是当系统出现故障时，如何处理请求或者当系统面对大量的并发请求时能否正常响应；易用性是指该系统提供给业务开发人员的API接口是否足够方便、给运维人员提供的接口是否足够丰富。
TDSQL在这两个方面做的都比较出色，下面简单介绍下其关键特性：
1、数据一致性
TDSQL基于MySQL的 binlog的严格有序性以及强同步复制机制，结合Raft协议的一些设计思想保证了数据的一致性，Raft协议的核心就是同步机制和选举机制，下面简述TDSQL的同步机制和集群中的选举机制。
基于Set机制的同步机制：TDSQL所有的高可用机制均是在Set之内实现，每个Set之内多个数据节点，主备之间可以是基于Raft协议的强同步复制机制，也可以是异步复制机制；
Leader选举：MySQL节点本身无法直接参与选举的，在TDSQL是通过Scheduler模块来负责选举的。如果主机发生故障，Scheduler会从两个备机中，选择一个数据较新的备（MySQL的 Binlog日志是严格有序的，所以哪个同步主机binlog的偏移量更大，谁的数据就更新，对应的也会被选为主机。
2、高可用性
通过多副本冗余和故障的自动切换机制，解决了单点问题，确保在单机、单IDC甚至整个城市灾难时，服务能够持续可用。
3、强同步机制
TDSQL的强通同步机制基于MySQL半同步复制，并进行了优化，对于进入集群的每笔更新操作，都将发到对应Set的主机上，主机会将Binlog发往两个备机，且收到其中任意一个备机应答后（仅仅是备机收到了Binlog，但可能还没有执行该Binlog），然后才本地提交，并返回给客户端应答，这就能确保数据零丢失。但是强同步机制在一定程度上会影响系统的性能。
4、自动扩容
TDSQL引入集群机制，实现了自动的容量伸缩，确保在业务访问量飙升时候，整个集群可以进行自动扩容来应对，这种扩容应该是动摇的，对业务应该完全透明，无需业务停机。
目前TDSQL有两个分支版本，一个是No-Sharding版本，一个是Group-Sharding版本，NS版本不支持自动扩容，GS版本支持自动扩容，但是该版本不支持跨节点事务和join。
5、分布式事务
分布式事务本质上还是为了解决在分布式系统中数据一致性的问题。对于分布式的数据库，存在存储副本以及数据库本身的分库分表等问题使得一个事务中存在着对不同节点的操作。
这就是典型的分布式事务。TDSQL基于MySQL的XA实现了分布式事务机制，在性能损失较低的情况下保证了系统中数据的一致性。
6、完整的自动化运营体系
TDSQL的整个集群架构中包括自动化运营发布平台、机器资源自动管理平台、智能监控平台和数据库智能诊断平台等。
7、完善的周边配套设施
TDSQL提供Binlog订阅，冷备系统和多源同步系统等。
1
Part5 TDSQL 常见部署方案
TDSQL 99.99%的高可用性使得它在面对不同的业务场景时都有对应的架构部署方案，常见的有同城跨IDC架构、两地三中心架构、两地四中心结构和多地多中心结构，下面来介绍下不同部署架构的主要特点：
1、同城单中心的架构
这种架构一般用作测试、异地灾备的机房或者业务不能容忍跨数据中心访问带来的网络延迟。每个数据库实例采用三个节点的模式，主备机需要跨不同的机架，主机宕掉之后，TDSQL会在40s左右完成自动地切换，业务基本无感知。
部署的架构如下图所示：
2、同城三中心的架构
每个数据库实例采用三个节点的模式部署，分布在3个IDC。业务系统支持多活模式部署每个IDC内的业务系统访问本IDC内LVS/TGW对应的虚拟IP，由其后端的Proxy模块将请求路由到正确的主备数据库节点。对于读写分离的请求优先访问本IDC的备机，任何一个数据库节点宕掉时，TDSQL会在40秒左右完成自动切换。
部署的架构图如下：
3、两地三中心结构
这种架构是同城两个中心+异地的中心，可以提供非常好的可用性和一致性，是TDSQL主要推荐的部署模式。每个数据库实例采用4-6个节点的模式，分布在3个IDC，业务系统支持多活模式的部署。
