深度揭秘腾讯云数据库技术7年变迁史

早在上个世纪50、60年代，“数据”二字就已再也不是简单的数字信息而已。随着信息技术的不断发展，在计算机应用领域，计算机存储和处理的对象逐渐普遍，表示这些对象的数据也随之变得愈来愈复杂，数据库这一门新兴学科的应用也愈来愈普遍。

纵观国内几大云服务商过去几年在云数据库领域的发展，腾讯云基于自身的业务场景以及技术研发能力，在云数据库市场上也经历了从利用开源到定制适配，再到自主研发的历程。

跟不少互联网公司不一样的是，腾讯初始的业务发展并未对数据库有过强依赖。与最初需使用Oracle等商业数据库的IOE厂商相比，腾讯云数据库的起步是从KV与存储分析的类型开始，而后逐步过渡到关系型数据库的使用上来的。

所以，腾讯内部是没有去IOE的过程，那么腾讯是以何种路线逐步进阶数据库的？这还得先从腾讯云数据库的发展历程提及，其发展历程整体来讲能够分为两条线：

1. 迎接开源——开源定制参与回馈开源——为云而生定制——适配客户需求。

一开始，腾讯云数据库建设主要引入了当时业界较为主流的开源数据库，如MySQL，Redis，PostgreSQL等。随后针对云上客户定制需求，腾讯云在数据库中衍生研发了如数据库并行复制、审计日志、在线加字段等核心功能，并计划逐步将以上功能回馈给MariaDB和MySQL社区。

1. 内部自研——业务倒逼技术发展——云化支撑——走进互联网及传统行业。

对于腾讯云自研的数据库，主要分为两类，一类是为腾讯内部业务适配而生的自研数据库，典型表明是TDSQL。另外一类是基于服务海量客户，由开源数据库适配业务自主研发的数据库，好比企业级云原生数据库CynosDB。若是说节省运维以及人力成本是云数据库1.0时代的特征，到了2.0时代，云数据库要在根本上具有自建数据库没法比拟的优点，才能成为支持用户业务运转不可撼动的基石。

能够说，在腾讯自研数据库历史上，腾讯分布式数据库TDSQL & 企业级云原生数据库CynosDB具备重要的历史节点。接下来，咱们将从架构等细节着手，为你们详细介绍这两款数据库背后的技术进阶和研发历程。

历经十年打磨的TDSQL技术全解析

TDSQL完美解决了金融等系统中高可用、数据一致性、水平伸缩问题。2002年，腾讯技术团队选择彻底开源MySQL构建数据库体系，为了解决计费等公司级敏感业务高可用、核心数据的零流失、核心交易的零错帐等问题，腾讯从07年开始自研了一款数据库产品，这也是TDSQL的前身，这款数据库在当时很好的支撑了09年的开放平台浪潮。

随着腾讯开放合做的发展扩大，行业场景愈来愈多，这款数据库没法很好的为合做伙伴提供服务，所以从2012年开始，由腾讯内部业务适配而衍生的自研数据库TDSQL正式诞生。那么，TDSQL 是如何实现自主可控和技术迭代的呢？

TDSQL 架构

从架构上讲，TDSQL 是 Shared-Nothing 架构的分布式数据库；从部署方式来说，TDSQL 是一款支持多租户的云数据库。总体来讲，TDSQL 是由决策调度集群 /GTM，SQLEngine、数据存储层等核心组件组成，其每一个模块都基于分布式架构设计，能够实现快速扩展，无缝切换，实时故障恢复等，经过这一架构，TDSQL 的 Noshard、Shard、TDSpark 实例能够混合部署在同一集群中。而且使用简单的 x86 服务器，能够搭建出相似于小型机、共享存储等同样稳定可靠的数据库。

在架构上，TDSQL 的核心思想有两个：数据的复制（replica）和分片（sharding），其它都是由此衍生出来的。其中：

 replica 配合故障的检测和切换，解决可用性问题；
 sharding 配合集群资源调度、访问路由管理等，解决容量伸缩问题。
 同时，因 replica 引入了数据多副本间的一致性问题和总体吞吐量降低的问题，而 sharding 的引入也会带来必定的功能约束。在最终实现上，TDSQL 由 Scheduler、Gateway、Agent 三个核心组件加上 MySQL 组成，其中：
 Scheduler 是管理调度器，内部又分为 zookeeper 和 scheduler server；
 Gateway为接入网关，多个网关组成一个接入层；
 Agent 是执行代理，与 MySQL 实例一块儿，构成数据节点。多个数据节点构成服务单元 SET。

TDSQL 面向数据一致性考验

在金融行业，银行、风控、渠道等第三方一般经过读写分离方式来查询数据，而在互联网行业，因为 x86 相对较高的故障率，致使数据可能常常性的出现错乱、丢失场景。为了解决这个问题，就必需要求主从数据保持强一致和良好的读写分离策略。而其中的关键在于如何实现强同步复制技术。

因为 MySQL 的半同步和 Galera 模式不只对性能的损耗是很是大的，并且数据同步有大量毛刺，这给金融业务同城双中心或两地三中心架构容灾架构带来了极大的挑战。为何会这样呢？

从 1996 年的 MySQL3.1.1.1 版本开始，业务数据库一般跑在内网，网络环境基本较好，所以 MySQL 采用的是每一个链接一个线程的模型，这套模型最大的好处就是开发特别简单，线程内部都是同步调用，只要不访问外部接口，支撑每秒几百上千的请求量也基本够用，由于大部分状况下 IO 是瓶颈。

但随着当前硬件的发展，尤为是 ssd 等硬件出现，IO 基本上再也不是瓶颈，如再采用这套模型，并采用阻塞的方式调用延迟较大的外部接口，则 CPU 都会阻塞在网络应答上了，性能天然上不去。

为了解决这些问题，TDSQL 引入了线程池，将数据库线程池模型 (执行 SQL 的逻辑) 针对不一样网络环境进行优化，并支持组提交方案。例如，在 binlog 复制方案上将复制线程分解：

1. 任务执行到写 binlog 为止，而后将会话保存到 session 中，接着执行下一轮循环去处理其它请求了，这样就避免让线程阻塞等待应答
2. MySQL 自身负责主备同步的 dump 线程会将 binlog 当即发送出去，备机的 io 线程收到 binlog 并写入到 relaylog 以后，再经过 udp 给主机一个应答
3. 在主机上，开一组线程来处理应答，收到应答以后找到对应的会话，执行下半部分的 commit，send 应答，绑定到 epoll 等操做。绑定到 epoll 以后这个链接又能够被其它线程检测到并执行。

改造后， TDSQL 基本能够应对复杂的网络模型。但上述方案还有小缺陷：当主机故障，binlog 没有来得及发送到远端，虽然此时不会返回给业务成功，备机上不存在这笔数据，然而在主机故障自愈后，主机会多出来这笔事务的数据。解决方法是对新增的事务根据 row 格式的 binlog 作闪回，这样就有效解决了数据强一致的问题。

基于规则和基于代价的查询引擎

当前大多数分布式数据库都设计的是基于规则的查询引擎 (RBO)，这意味着，它有着一套严格的使用规则，只要你按照它去写 SQL 语句，不管数据表中的内容怎样，也不会影响到你的“执行计划”，但这意味着该规则复杂的数据计算需求不“敏感”。虽然金融业务都有本身的数据仓库，然而也会常常须要在 OLTP 类业务中执行事务、Join 甚至批处理。

TDSQL 在 SQLENGINE 实现了基于代价的查询引擎 (CBO)，SQL 通过 SQLENGINE 的词法、语法解析、语义分析和 SQL 优化以后，会生成分布式的查询计划，并根据数据路由策略（基于代价的查询引擎）进行下推计算，最后对汇总的数据返回给前端。

而做为分布式的计算引擎，在存储与计算引擎相分离的状况下，很是重要的一环就是如何将计算尽可能下推的下面的数据存储层。所以 TDSQL 的 SQLENGINE 在通过大量业务打磨后，实现了基于 shard key 下推、索引条件下推、驱动表结果下推、null 下推、子查询下推、left join 转化成 inner join 等多达 18 种下推优化手段，尽可能下降数据在多个节点传输带来的压力，以提供更好的分布式查询的能力，支撑金融交易的关联操做。

若是说腾讯云数据库历史是一部从蛰伏到发展再到突破的历史，那么能够说接下来CynosDB的推出，让腾讯云数据库迎来了新一轮的突破变迁。

真正云原生数据库CynosDB技术解析

2017年，在腾讯云服务了百万客户以后，腾讯云数据库迎来了突破。由开源数据库适配业务和具体场景，腾讯云自主研发了一款真正的云原生数据库CynosDB。做为腾讯云在数据库领域的重要布局，CynosDB单节点读性能能够达到130万QPS，全面超越业内目前最高的100万QPS水平。它将传统数据库与云计算的优点相结合，解决了传统数据库云上的难题，其设计思路能够归纳为如下几点：

1. 首先是计算存储分离，好比把运算CPU或者内存放在一块儿统一分配，能够得到弹性调度能力。
2. 第二个是日志下沉及异步回放，同时移除了数据页面的刷脏逻辑，这样下降了计算存储分离的架构下的网络开销。
3. 第三个是分布式存储，这也是咱们腾讯云自研的分布存储系统，共享的分布式存储能够横向扩展。
4. 第四个是后台的持续日志备份，传统数据库的备份是在数据库主机上去拷日志完成备份，而CynosDB的持续备份是在存储上进行，不干扰数据库实例，减轻因为备份对数据库的冲击，而且用户没必要关心备份策略和备份存储资源规划。

计算存储分离架构的实现和优化

这里须要重点说下计算和存储分离。传统数据库的优化演进历史，基本上是和IO作斗争的历史，由于数据库是有状态、重IO的服务，传统MySQL架构有多个IO类型，存储相同的文件，因此主机和备机的磁盘会有不少相同的IO和冗余的文件。即使数据库被搬上云，为了在云上作弹性的扩容，开发者依然面临传统数据库所面临的问题。

基于以上痛点， CynosDB以软件优化与新硬件结合为理念，采用了先进的计算和存储分离架构，同时实现了计算无节点状态，支持秒级故障切换和恢复，数据备份时间缩短到60秒以内，速度提高了180倍。

CynosDB架构有以下几个特色：

1. 日志即数据库。架构中只有日志流，于是只有日志能表达数据库；
2. IO卸载。除了日志，其余全部类型IO所有卸载，如数据文件、源数据文件、biglog文件等；
3. 无状态。本地文件将不复存在，包括日志文件，因此计算层是无状态的。

在新架构中，日志处理无可厚非具备很是重要的做用。其中连续的日志在存储层被打散成了不少的小的分片，分别存储在不一样的cell里。而日志处理的逻辑是将存储引擎将日志发给存储节点，存储节点将日志放到一个日志队列里面，并将其持久化，以后当即返回给存储引擎，当存储引擎得到日志的反馈后就能够将一部分事务提交。其中，存储节点会异步的进行一些操做，这些操做和事务的提交过程无关，不影响事务的提交响应速度。

而在数据库里面，若是buffer足够的话，数据库的写性能是和日志的落盘时间相关的，传统数据库组提交机制可能存在几个问题，一是若是有大量的链接进来，MySQL将会为每个链接建立一个线程，若是用户的业务没有链接管理，那么将会存在频繁的线程建立与销毁，浪费不少资源，同时，大量并发线程的锁冲突以及切换代价也会很是大。

针对以上问题，CynosDB引入了线程池，直接解决了资源管理和线程切换的问题，但线程池只适合处理短任务。为此，CynosDB同时引入了异步组提交的机制，基于线程池实现，再增长独立的日志写线程log writer，每个工做线程提交事务的时候，并非去作写和刷的操做，而是将本身的请求提交到一个提交队列里去，而后当即返回给Server层，以便释放本身的线程资源。若是某一段日志持久化成功以后，log writer会唤醒提交队列里面等待的请求，将其从新调度到线程池的高优先级队列，从新得到工做线程执行事务提交后的工做。如此一来就能高效的利用线程池的资源，同时作到资源的控制，避免上下文频繁切换带来的性能问题。

日志下沉、异步回放的关键设计

日志下沉是什么意思？好比开发者在一个页面作插入操做，生成的日志会放到日志管理子系统的日志buffer里，日志buffer的重用、刷新、并发管理等都是由数据库来作。CynosDB会把日志管理作成独立模块，并在CynosStore Client中实现。任何数据库若是想接入这个系统的话，都不用去关心日志管理，直接调相关接口完成日志记录便可。这里的日志和普通日志存在区别，好比PG的日志更偏向逻辑的概念，而CynosDB的日志，记录的是物理修改（对某页面的什么位置作了什么内容的修改）。另外，日志向日志buffer的插入过程是并行的，如有5个用户同时生成日志，往日志buffer copy都是并行进行的而非串行。

总结来讲，日志下沉是指DB层产生的日志都会放到CynosStore Client的buffer中，而后异步发送到分布式存储中，而不是存到本地。而在分布式存储中有一块固定的存储空间来专门存储日志，因为空间大小固定，所以在CynosStore中会有特定的线程，定时地把日志异步地合并到数据页面上，经过这种日志回收机制能够有效的利用日志空间，保证写的连续性。

CynosDB应用场景及将来规划

近日，腾讯云数据库CynosDB正式亮相MariaDB用户者大会，并受到了MariaDB基金会以及众多国际参会者的承认。

与此同时，腾讯云数据库产品总监王义成还向记者透露，今年Q3，CynosDB将会完全完成商业化。CynosDB的技术能力以及存储层早已具有按使用量计费的能力，计算层也正在进行相应的适配，待CynosDB商业化后将逐步推上日程。

因为CynosDB对主流开源数据库的兼容，以及快速弹性升级、海量数据存储等优点，王义成表示，CynosDB将来将持续落地应用于包括互联网及游戏等广阔的行业，帮助用户更好地应对业务高峰，加速业务创新。
后记
从2012年到2019年，这七年，腾讯云数据库无不见证、参与数据库技术发展史上的一次次突破与迭代。回望这段从开源到适配，从适配到自研的历程，腾讯云能够说将每一次经由业务适配考验后的思考、经验都化做数据库服务的“活水”，灌溉自身业务的同时也灌溉了开发者社区。

值得注意的是，在长达几十年的时间里，因为国内数据库市场启动较晚，国外巨头始终占据数据库绝对领先优点，使得国产数据库的发展十分艰难。将来，由云原生技术带来的一系列新技术与市场机遇，不只仅是对数据库管理员的挑战，也是对数据库产品内核与工具的考验，接下来腾讯云数据库“风”往何处吹？且看“行云”。

本文转载自InfoQ