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

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

跟很多互联网公司不同的是，腾讯初始的业务发展并未对数据库有过强依赖。与最初需使用 Oracle 等商业数据库的 IOE 厂商相比，腾讯云数据库的起步是从KV 与存储分析的类型开始，然后逐步过渡到关系型数据库的使用上来的。因此，腾讯内部是没有去 IOE 的过程，那么腾讯是以何种路线逐步进阶数据库的？这还得先从腾讯云数据库的发展历程说起，其发展历程总体来说可以分为两条线：

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

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

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

对于腾讯云自研的数据库，主要分为两类，一类是为腾讯内部业务适配而生的自研数据库，典型代表是 TDSQL。另一类是基于服务海量客户，由开源数据库适配业务自主研发的数据库，比如企业级云原生数据库 CynosDB。如果说节省运维以及人力成本是云数据库 1.0 时代的特征，到了 2.0 时代，云数据库要在根本上具备自建数据库无法比拟的优势，才能成为支持用户业务运转不可撼动的基石。可以说，在腾讯自研数据库历史上，腾讯分布式数据库 TDSQL& 企业级云原生数据库 CynosDB 具有重要的历史节点。接下来，我们将从架构等细节着手，为大家详细介绍这两款数据库背后的技术进阶和研发历程。

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

TDSQL 完美解决了金融等系统中高可用、数据一致性、水平伸缩问题。2002 年，腾讯技术团队选择完全开源 MySQL 构建数据库体系，为了解决计费等公司级敏感业务高可用、核心数据的零流失、核心交易的零错账等问题，腾讯从 07 年开始自研了一款数据库产品，这也是 TDSQL 的前身，这款数据库在当时很好的支撑了 09 年的开放平台浪潮。随着腾讯开放合作的发展扩大，行业场景越来越多，这款数据库无法很好的为合作伙伴提供服务，因此从 2012 年开始，由腾讯内部业务适配而衍生的自研数据库 TDSQL 正式诞生。那么，TDSQL 是如何实现自主可控和技术迭代的呢？

TDSQL 架构

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

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

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

TDSQL 面向数据一致性考验

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

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

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

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

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

任务执行到写 binlog 为止，然后将会话保存到 session 中，接着执行下一轮循环去处理其它请求了，这样就避免让线程阻塞等待应答
MySQL 自身负责主备同步的 dump 线程会将 binlog 立即发送出去，备机的 io 线程收到 binlog 并写入到 relaylog 之后，再通过 udp 给主机一个应答
在主机上，开一组线程来处理应答，收到应答之后找到对应的会话，执行下半部分的 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 水平。它将传统数据库与云计算的优势相结合，解决了传统数据库云上的难题，其设计思路可以概括为以下几点：

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

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

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

基于以上痛点，CynosDB 引入计算存储分离的架构，存储层使用共享的分布式块存储云服务，计算层则将不必要的 IO 全部卸载，实现计算与存储基于日志传输的新架构。

CynosDB 架构有如下几个特点：

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

在新架构中，日志处理无可厚非具有非常重要的作用。其中连续的日志在存储层被打散成了很多的小的分片，分别存储在不同的 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 中会有特定的线程，定时地把日志异步地合并到数据页面上，通过这种日志回收机制可以有效的利用日志空间，保证写的连续性。