拓路前行 -TDSQL 追求极致体验的这一路

2007 年，计费平台的一帮年轻人为了实现银行级的高可用、零错账的交易系统，加班加点讨论方案，长达几个月的反复头脑风暴与论证，终于提出了“TBOSS 7*24”容灾方案，并用了一年多时间落地推广后，斩获 09 年公司级技术突破奖，获得了 Tony 的首肯，从此开启了计费平台打造金融级数据库的探索之路。

一路走来，技术追求永无止境，打造一款更好用的高一致、高可用、高性能分布式数据库产品的初心从未改变，系统架构历经三代优化，2012 年立项的第四代产品 TDSQL，经过 5 年打磨与海量业务的实际运营优化，并与腾讯金融云合作产品化，正式以腾讯云金融级数据库对外输出，目前 500+金融客户覆盖银行、保险、基金证券、消费金融、第三方支付、计费、物联网、政企等多个领域，尤其在多家银行的核心交易系统落地，标志着 TDSQL 真正突破成为一款金融级数据库产品，正是这里的突破，使得项目团队今年再次斩获公司级技术突破奖，这也是公司对团队一直专注金融级数据库底层研发耕耘的认可。

当然，道阻且长，随着硬件不断在更新，业务越来越多样且复杂，数据库领域还有许多新的挑战还需我们去攻克。本文尝试着记录下过去十年一路摸爬滚打过程中，团队的一些思考与总结，希望后面的路越走越宽！

从本质上来说，数据库产品要考虑的问题依然还是用户体验的问题！细化来说，数据库产品主要有两类直接用户，分别是开发人员与运维人员，核心就是他们要用得爽。

例如对开发人员来说，他们经常关心的问题有：

1、开发接口是不是标准的？是否提供完善的开发指引？

2、在故障灾难出现时，开发人员需不需要关心数据是否会丢失？需不需要写很复杂的容灾切换逻辑？

3、系统性能好不好，能不能扛住业务浪涌式压力？

4、系统是否足够开放等等？

而对于运维人员 DBA 来说，他们经常关心的问题如：

1、系统的常规操作是否有标准化的工具或页面直接使用？

2、系统是否足够透明，使得在异常时，能否快速的定位问题？

3、是否提供了完善的系统运营手册？

4、配套设施是否完善，例如监控系统、发布系统、冷备系统、审计系统等等？

当然也还有一类间接用户，那就是这些使用数据库的业务系统的真实用户，他们关心的问题有：

1、他们的支付、转账等操作是不是正常的，会不会不到账，多扣钱？

2、他们是否能够随时随地发起交易等等？

通常来说，在资源和时间有限的情况下，这几类用户的需求是要区分不同优先级的，甚至有时候是冲突的，所以我们一路走来，始终保持这样一个原则：在保障用户的基本诉求（数据不丢，不错账）的情况下，然后不断优化开发人员与运维人员的使用体验。例如我们的第一代产品“TBOSS 7*24”就是优先保证高可用、高一致性，确保用户数据不错不丢，但是极大的损害了开发人员与运维人员的体验，需要业务开发人员开发大量的容灾代码，运维人员需要维护大量的灾难模式等，也就是说很多工作交给了业务开发与运维人员。在后面的几代系统更迭中，我们就是不断的将功能下沉，让业务开发和运维越来越简单，必然的数据库本身会更加复杂一些。尽可能的在数据库层面去解决三类用户的诉求，也就变成了 TDSQL 的核心挑战。

TDSQL 的核心挑战

TDSQL 经历大大小小无数版本，始终面对的核心挑战是：

1、数据的可靠性。在任何灾难情况下，例如主机故障、网络故障等等，都不能存在数据丢失的情况。

2、系统的可用性。基于数据多副本的情况下，系统如何保证在一些异常情况下，快速恢复可用，把不可用时长降至最低。

3、高性能。首先，单机性能提升，对于海量业务来说，能够极大的降低服务器等成本；其次，性能指标也是用户最能直接感受到的指标之一，所以性能优化一直是我们优先级最高的任务之一。

4、扩展性。也就是通常说的分布式。其实在金融行业，之前对分布式这块的需求并不大，但是随着第三方支付的快速发展，给银行的一些系统造成了很大的冲击，例如双 11、春节红包等活动，这类系统使用传统的 IOE 架构很吃力，所以他们也希望能采用分布式架构来解决这个问题。抛开从思维层面，分布式架构对传统金融 IT 行业人员的冲击外，其实从技术上来说，这里其实挑战很多，TDSQL 也是在逐步的优化与解决，例如最复杂的两个点分布式事务与分布式 Join 操作。目前我们已经完成了分布式事务功能的发布，而分布式 Join 还在内测过程中。

5、配套工具。一个数据库软件要体验好，那么就不能仅仅提供几个核心的包，必须要有相应的运营管理工具、问题诊断工具、性能分析工具等，并且是一个开放的、标准的接口，只有这样大家才能更好更无缝的使用。

上面的几个问题，前面 2 个是基本功能的问题，在第一个版本就已经基本保障了，但是是不是就足够了？远远不够，路走得不够多，遇到的坎太少，碰到新的坑时，依然可能会摔跤。我们只有在足够丰富的场景中，通过大量的实践运营经验，使得自己的系统经历足够的磨练，才能使得系统的可用性和数据可靠性保持足够多的 9。后面几个问题，本身也应该是一个持续优化的过程，TDSQL 也一直在寻找最优雅的方式去解决，所以下面就从这几个问题，看看 TDSQL 具体是如何做的。

核心架构

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

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

**分布式事务。**TDSQL 基于 MySQL 的 XA 实现了分布式事务机制，对各种异常处理做了充分的鲁棒测试，且相对于单机事务，性能损失仅 30%。

高级特性

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

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

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

内核优化

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

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

性能优化。

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

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

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

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

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

安全增强。在安全方面做了大量优化及增强，包括数据文件加密、SQL 防火墙、SSL 接入、安全审计等。

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

部署方案

TDSQL 的强同步机制，本身是可以做到全球化部署的，但其实我们绝大部分客户无论是成本看，还是从业务场景看，都不需要做全球部署，常见的两地多中心基本都能满足需求。客户可以基于成本、自身业务数据的容灾要求，以及数据中心分布情况，选择不同的部署方案。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 的开发者和运维 DBA 来说，其配套设施、可维护性、透明性等至关重要，因为这决定了他们能否及时发现问题，针对问题能快速的做出变更及应对。所以 TDSQL 经过这两年的产品化工作，提供完善的周边配套体系，例如：

1）冷备系统。基于 HDFS 或其他分布式文件系统，可以做到自动备份，一键恢复。

2）消息队列。基于 Kafka 定制的 Binlog 订阅服务。基于该消息队列，TDSQL 还提供了 SQL 审计、多源同步（相同表结构的数据合并到一张表）等服务。

3）资源管理。基于 cgroup 的对 TDSQL 实例进行编排，提高机器资源利用率。

4）OSS。对 TDSQL 的所有操作，例如扩容、备份、恢复、手动切换、申请（修改／删除）实例等操作，均提供统一的 HTTP 接口，可以有效自动化，降低人肉运维的风险。

5）数据采集。TDSQL 所有的内部运营状态或数据，都能实时采集到，业务可以基于这些数据做定制分析或者构建运营监控平台。

6）监控平台。业务可以基于数据采集模块采集到的所有数据，对接自建的监控系统，亦可直接使用 TDSQL 自带的监控系统（需单独部署）。

7）管理平台。基于以上模块，TDSQL 自带运营管理平台（内部平台代号赤兔），DBA 基本上可以通过该管理台进行所有常规的运营操作，不再需要登录后台。

8）审计模块。审计模块通过对用户访问数据库行为的日志采集及分析，用来帮助客户事后生成合规报告、事故追根溯源，同时加强内外部数据库网络行为记录，提高数据资产安全。

以上这些模块可以自由组合，没有强依赖关系，运维人员也可以通过 TDSQL 的提供的接口自行对接自己现有的平台（如监控、告警、审计等）。

写在最后

TDSQL 一路走来，在可靠性、可用性、性能、扩展性、配套设施等方面取得了一些里程碑式的成果，但是远没有到极致的用户体验。例如我们定位是 OLTP 数据库，适合高并发短事务的场景，但客户有时候需要在数据库上跑一些的 OLAP 操作，那这块我们能不能做？如何做？目前的分布式还无法真正做到一个单机数据库使用，那么在未来硬件发展情况下，能否做到呢？类似这些挑战还很多，数据库研发这块道阻且长，与大家共勉。