TDSQL 是腾讯提供的一套完整的 MySQL 数据库集群化管理解决方案，作为私有云 TStack 平台重要的数据库产品能力，旨在解决高可用、高性能、分布式、配套设施等方面问题。

TDSQL 除了在腾讯内部有大量的使用场景，在外部市场中也有诸多应用场景；2014 年被 WeBank 选中，作为其核心交易系统的数据库解决方案，以私有云方式交付；2015 年，在腾讯云上正式推出。目前已经为 500+机构提供数据库的公有云及专有云服务，客户覆盖计费、第三方支付、银行、保险、互联网金融、物联网、互联网+、政务等领域。

TDSQL 私有云版本的核心思路是：标准化、模块化、丰俭由人！

例如 TDSQL 的模块设计是充分解耦的，彼此之间通过接口衔接，客户可以自行组装或用自己现有模块替换；又比如在设计部署架构时，客户可在成本（自身数据中心建设情况），业务数据安全可靠性、业务可用性三者之间做不同的平衡选择，可以做到 N 地 N 中心的部署，数据副本亦可做到一主 N 备（N>=0）；甚至在设计读写分离机制时，只读账户可根据主备延迟状态，选择是从备机读取，还是从主机读取，还是直接返回错误；数据库引擎，TDSQL 也提供 MariaDB、Percona、MySQL 社区版三个版本支持。类似这样的设计贯穿 TDSQL 私有云版本的整个研发过程，以给予客户足够的灵活性和选择权。

TDSQL 关键特性

** 数据可靠性**在各种异常灾难情况下，例如主机故障、网络故障、数据中心故障等，都能确保数据安全可靠。系统可用性基于数据多副本，系统保证在各种异常灾难情况下，可根据客户不同的数据可靠性级别，快速恢复可用，把不可用时长降至最低。强同步数据节点之间自动切换，RTO 为 40s，RPO 为 0。** 高性能**对 MySQL 三大分支（MariaDB、Percona、MySQL community）深度优化，使得在主备网络延迟 5ms 的情况下，能做到跨 IDC 强同步性能相较于异步同步零损耗；同时 sysbench OLTP TPS 数据是原生版本 185%。水平扩展性提供 Auto Sharding 机制，可实现实时在线无缝扩容，确保集群性能和容量呈线性增长；同时提供健壮的分布式事务机制，在性能损耗极低(损耗 30%)的情况下，大大降低了传统业务迁移分布式架构的难度。自动化运营提供完善的运营体系，自动化运营发布平台，机器资源自动管理，智能监控平台及展示，数据库智能诊断等。配套设施 TDSQL 还提供 Binlog 订阅、安全审计、冷备系统、多源同步等配套系统，供客户选择。

核心架构

Set 机制

TDSQL 所有的高可用机制均是在 Set 之内实现，每个 Set 之内多个数据节点（1 主 N 备），主备之间可以是基于 Raft 协议的强同步复制机制，也可以是异步复制机制。在主机出现故障的情况下，在调度模块的协助下，将挑选备机按照规定流程提升为主机，快速恢复业务，全程无需人工干预。在我们常规的使用过程中，通常是建议 1 主 2 备，主备之间强同步，这样在主节点故障情况下，能确保自动切换，RTO 为 40s，RPO 为 0。

水平扩容

分布式版本对外呈现为一个完整的逻辑实例，后端数据实际上是分布在若干 Set 上（独立的物理节点）组成。逻辑实例屏蔽了物理层实际存储规则，业务无需关心数据层如何存储，也无需在业务代码中集成拆分方案或再购买中间件，只需要像使用集中式（单机）数据库一样使用即可。同时支持实时在线扩容，扩容过程对业务完全透明，无需业务停机，扩容时仅部分分片存在秒级的只读（只读是实际在做数据校验），整个集群不会受影响。

分布式事务

TDSQL 基于 MySQL 的 XA 实现了分布式事务机制，对各种异常处理做了充分的鲁棒测试（发现了 10 多个 XA 相关的 Bug 并进行修复提交到社区，并做了大量性能方便的改进，扩展了事务状态方面的统计信息以实现全局分布式死锁检测），且相对于单机事务，性能损失仅 30%。

高级特性

二级分区

第一级即我们常说的水平拆分，原理是使用 HASH 算法，使得数据能均匀的分散到后端的所有节点；第二级分区使用 RANGE 算法，使得相关的数据能够落在一个逻辑分区，例如可以按时间分区（类似每天每周每月一个分区等），亦可以按业务特性分区（类似每个省市一个分区等）等等。二级分片可以均衡数据分布和访问，为快速一键扩容提供基础支撑，也可以满足快速删除数据等场景。

读写分离

基于数据库访问账号的读写分离方案，客户能基于业务需求对账号设定相关参数，以确保既不会读取到过旧的数据，也不会影响写业务，且业务无需改动代码即可实现读写分离。这可以极大的降低业务运营成本。

此外，TDSQL 还有全局唯一数字序列、统一参数管理、兼容 MySQL 函数，热点更新等众多高级特性，可满足各类业务需求。

内核优化

TDSQL 在数据库内核这块的优化，主要集中在数据复制、性能、安全性等方面。

强同步机制

TDSQL 针对金融场景的强同步机制，有效解决了 MySQL 原生半同步机制的问题：性能降低以及超时退化为异步。目前 TDSQL 在强同步模式下，系统的并发量（TPS/QPS）与异步模式已无差别，基本能做到性能无损失。

性能优化

1、我们对 MariaDB/Percona 的线程池调度算法进行了优化，改进当系统处于重负载时，查询和更新请求在线程组间分布不均衡等极端情况。并且能够更好地利用计算资源，减少无谓的线程切换，减少请求在队列中的等待时间，及时处理请求。

2、组提交（Group Commit）的异步化。工作线程在其会话状态进入组提交队列后，不再阻塞等待组提交的 Leader 线程完成提交，而是直接返回处理下一个请求。

3、InnoDBBuffer Pool 使用优化。例如全表扫描时，避免占满 InnoDB Buffer Pool，而是只取一块来使用。

4、InnoDB 在 MySQL 组提交期间避免与组提交有 mutex 冲突的活动，例如 InnoDB Purge，降低冲突，以提升性能。

类似的性能优化的点，还有不少，可能在某些场景下，单个点效果不明显，但是集合起来看，目前性能指标整体是不错的。基于 Sysbench OLTP 测试结果，相同的硬件及测试环境下，TDSQL 性能相比原生版本提升 85%。

此外，我们长期关注 MySQL 的三个分支版本：MariaDB、Percona、MySQL community，对于社区的新特性，也会定期的合入。

部署方案

基于成本因素考虑，客户可根据自身业务数据的容灾要求，以及数据中心分布情况，选择不同的部署方案。TDSQL 可以针对客户不同的数据中心架构，在数据可靠性与可用性上做出权衡，做到灵活部署。目前常见的两种部署方案包括：

两地三中心

该方案，ZK 分布在两地的三个中心内。

 1、主IDC故障不会丢数据，自动切换到备IDC，此时蜕化成单个IDC的强同步。
 2、仅仅主机故障，在对比两个同城备节点及一个同城Watcher节点后，切换到数据最新的节点，优先选择同IDC的Watcher节点，尽可能减少跨IDC切换。
 3、备IDC故障，通过另外一个城市的ZK能自动做出选举：
     a) 备IDC确实故障，自动提升主IDC的Watcher节点为Slave,由主提供服务。
     b) 主备网络不通，与a)一样的处理方式。

两地四中心

该方案适应性最强，但是对机房数量要求也高一些。

  1、同城三中心集群化部署，简化同步策略，运营简单，数据可用性、一致性高
  2、单中心故障不影响数据服务
  3、 深圳生产集群三中心多活
  4、 整个城市故障可以人工切换

周边配套

对于私有云客户来说，数据库产品其配套设施、可维护性、透明性等对于客户来说至关重要，因为这决定了他们能否及时发现问题，针对问题能快速的做出变更及应对。所以 TDSQL 私有云版本，提供完善的周边配套体系。

冷备系统基于 HDFS 或其他分布式文件系统，可以做到自动备份，一键恢复，支持物理备份，逻辑备份，增量备份等各种策略。消息队列基于 Kafka 定制的 Binlog 订阅服务。基于该消息队列，TDSQL 还提供了 SQL 审计、多源同步（相同表结构的数据合并到一张表）等服务。资源管理基于 cgroup 的对 TDSQL 实例进行编排，提高机器资源利用率。OSS 对 TDSQL 的所有操作，例如扩容、备份、恢复、手动切换、申请（修改／删除）实例等操作，均提供统一的 HTTPS 接口，可以有效自动化，降低人肉运维的风险。数据采集 TDSQL 所有的内部运营状态或数据，都能实时采集到，业务可以基于这些数据做定制分析或者构建运营监控平台。监控平台业务可以基于数据采集模块采集到的所有数据，对接自建的监控系统，亦可直接使用 TDSQL 自带的监控系统。管理平台基于以上模块，TDSQL 自带运营管理平台（内部平台代号赤兔），DBA 基本上可以通过该管理台进行所有常规的运营操作，不再需要登录后台。审计模块审计模块通过对用户访问数据库行为的日志采集及分析，用来帮助客户事后生成合规报告、事故追根溯源，同时加强内外部数据库网络行为记录，提高数据资产安全。以上这些模块可以自由组合，没有强依赖关系，客户也可以通过 TDSQL 的提供的接口自行对接自己现有的平台（如监控、告警、审计等）

写在最后

TDSQL 经过多年发展，上面提到的特性，均在腾讯内部的海量业务实践运营过程中得到检验，这也是 TDSQL 对外版本发布的基本原则：只有经过现网运营验证并觉得充分成熟的特性，才会发布给客户。