腾讯云TDSQL-C 全球数据库技术揭秘

本文内容节选自6月13日，由msup和高可用架构联合主办GIAC全球互联网架构大会，腾讯云数据库技术专家冉仟元分享的《TDSQL-C 全球数据库技术揭秘》案例实录。

图片

01.

分享者

冉仟元，有10余年的数据库存储开发经历，曾供职于华为、阿里巴巴、字节跳动，2023年加入腾讯云数据库云原生研发团队，目前负责TDSQL-C（for MySQL）技术方向。主要关注高性能计算网络、分布式存储方向。

TDSQL-C是腾讯云自研的新一代云原生关系型数据库。融合了传统数据库、云计算与新硬件技术的优势，为用户提供具备高弹性、高性能、海量存储、安全可靠的数据库服务。

TDSQL-C MySQL版100%兼容MySQL 5.7、8.0。实现超百万级QPS的高吞吐，最高 PB 级智能存储，保障数据安全可靠。

TDSQL-C采用存储和计算分离的架构，所有计算节点共享一份数据，提供秒级的配置升降级、故障恢复，单节点可支持百万级QPS，自动维护数据和备份，最高以GB/秒的速度并行回档。

02.TDSQL-C 技术架构演进

TDSQL-C 技术演进路线

传统MySQL架构存在的痛点：存储容量受限于本地磁盘，无法支撑超大规模实例；主从延迟高达秒级，DDL操作与大事务会进一步加剧延迟问题；只读备机构建速度缓慢（分钟或小时级），垂直与水平扩缩容能力差；读副本需冗余存储，且存在严重的写放大等问题。

TDSQL-C的初始目标就是朝着解决这些问题。

TDSQL-C最开始是基于“Log is Database”这种架构，这种架构最小化网络IO，存储层能解析Redo Log。内核和存储深度组合优化，避免了RW节点页面刷脏，Checkpoint等行为。同时存储层内嵌了数据库内核部分功能，性能和扩展性更强。

另外，随着一些外部客户的需求以及技术迭代的演进，最近一年我们也在探索和实现对等架构，这种架构支持多个写节点，写性能进一步提升；算子下推结合内核并行查询能力，提升HTAP处理能力。

TDSQL-C 产品演进路线

2017-2019

2017年立项，基于存算分离架构，解决数据库独立、弹性伸缩问题，满足云原生数据库业务诉求。

2019年正式商业化，成为国内首批Log is Database架构的云原生数据库产品。

2023

并行查询和列存索引功能相继发布，TDSQL-C的HTAP能力增强，复杂查询效率提升4-17倍。

2021

发布Serverless版本，是国内首个使用Serverless架构的云原生数据库，为超10万企业用户及50万微信小程序开发者提供服务，助力传统企业数字化转型。

2025

即将发布TDSQL-C全球数据库版本，实现分布在全球不同地域的多个TDSQL-C集群间数据同步，助力全球业务轻松出海部署。

TencentDB  

03.TDSQL-C 全球数据库核心技术解析

全球数据库架构

全球数据库是一个可跨城市、跨国甚至跨洲际部署的数据库网络集群，不同区域间有全量数据集，通过高效物理复制同步数据。

支持一个主Region，最多7个从Region，每个Region可挂载15个RO，分担读压力，实现区域内就近读，多地部署提供全球容灾能力。

图片

主Region中，写请求生成的Redo日志持久化至高速存储引擎Logstore，并备份至对象存储COS；从Region通过Standby节点同步Redo日志，该Region内的其他RO节点则链接该Standby节点，获取日志进行内存更新，从而提供一致的数据读服务。

若从Region接收到写请求，会通过Proxy或内核直连透明转发至主Region执行，确保全局数据一致性。

底层存储引擎 DBStore 3.0

为支持全球数据库功能，底层存储引擎DBStore从2.0升级到3.0。

图片

（一）DBStore 2.0架构

2.0存储层的设计和实现，着重体现了“Log is Database”的理念，其含义是日志中包含了数据的信息，可以从日志中恢复出用户的数据，这种架构带来的好处是：

• 计算层完全无状态，为秒级节点升配、秒级增加从库提供基础；
• 计算层无页面恢复开销，缩短启动时间；
• 避免页面刷脏，从根本上减少了计算节点B+Tree的写放大问题，减少计算层和存储层的I/O量。

而DBStore作为可计算存储，主要承担着持久化日志、回放日志、读写数据页面，提供多版本等功能。

随着业务需求的不断变化，以及更极致性能的诉求，DBStore 2.0在发展过程中也面临着一些问题：Redo日志按小表粒度打散存储到DBStore中，按当前设计，如果需要获取连续的日志备份及定阅能力，需更重新设计存储格式和索引，复杂且性能损耗；

（二）DBStore 3.0架构

引入LogStore组件，主要用于接收和存储Redo日志，同时升级了PageStore的主要功能。

• 性能提升 ：LogStore主要用于持久化日志，dbclient无需解析，流式的日志发送提升了前台写日志速度，PageStore主要负责后台异步批量分发和部分计算功能。通过逻辑解耦的方式使各个组件发挥自己的架构优势，突破性能上限。相比有主架构，dbclient到LogStore链路采用无主架构，减少网络延时，消除长尾毛刺影响。

日志功能增强

为满足Standby全量数据集需求，主库需提供连续的日志流。除内存日志外，还需要提供订阅冷日志的能力。

两个模块：Log Ring Buffer（内存区域存储最近日志）和CDP Agent（从存储订阅一段范围的日志）。

当Standby 请求日志时，如果日志范围在Ring Buffer内，则从内存读取，否则下发给 CDP ，从LogStore或COS获取。对数据库实例而言，日志获取透明。

Standby在从主库读取到日志后，会拷贝一份用于异步发送到存储进行数据更新，另一份则用于更新其内存中的数据页。

发送效率优化

由于全球数据库可能跨洲际部署，网络延迟大。例如广州到美国圣克拉拉，单线程发送日志上限仅15MB/秒，无法满足生产环境数据复制低延迟要求。

解决方案：主库通过多线程并发提高发送效率。主库为每个Standby Dump请求生成一个协调线程和多个Worker线程，协调线程从Log Buffer或者CDP中获取一段区域的日志，然后计算好并行执行的分片，每个Worker 线程发送各自分片到Standby，Standby接收线程拷贝日志到本地，进行持久化和内存应用。

从测试来看，线程数与传输效率基本成正比，16个线程可以满足大部分场景，24个线程可以满足高吞吐下的全球复制。

图片

可用区切换

可用区切换，这里主要分为两种，一种是计划内切换：比如需要为全球数据库进行版本更新，或者用户负载发生变化主动进行切换。

另一种是计划外切换，这通常是遇到不可抗力，例如整个可用区完全不可用，为了保证服务的连续，需要将另外一个可用区提升为主Region。

计划内切换：一个主Region和两个从Region, 在具体实现中，我们首先将Primary降级为Standby并写入一条降级日志，之后不可再接受任何写操作。

其他Region的Standby接受到降级日志，会将自己设置为可升级状态，表示数据已经完全同步。

然后我们选择一个可升级的Standby，将其在线修改为Primary, 然后通过CHANGE MASTER命令将其他Standby指向新的Primary, 这样计划内的可用区切换就完成了。

图片

计划外切换 ：当可用区故障，需要进行非计划内切换时，管控通过收集到的信息，选择一个日志最全的节点作为备选Primary, 在提升为Primary接受写服务之前，需要确保日志完全应用完，未完成的事务，从Undo恢复出来，在后台进行回滚，然后才能正式提升为Primary并接受写请求。

其他从Region的Standby则指向新的Primary，请求日志，对于旧Region, 当其恢复可用后，由于我们已经选举了新的主库，因此其数据已经不可用，需要进行重建，并从新主库复制数据。

通常在完全恢复全球数据库集群后，可能还需要进行一次计划内切换，将原可用区恢复成主Region, 这取决于用户的写负载是否具有区域性。

图片

写转发

全球数据库支持写转发能力，发送到从Region的写请求，既可以通过Proxy进行写转发，也可以通过数据库内核进行写转发，这对用户客户端来说都是透明的，理论上来说，我们支持任意类型的写转发。

当写转发后，如果随后发起数据读，根据需求，可能会有不一样的一致性，这里支持三种一致性级别：最终一致性，会话一致性和全局一致性。

客户端在备库上发送一个开启事务的指令，这个指令会发送到Primary，同步的开启一个事务，随后针对三种一致性配置，可能会有不同的行为。

随着用户提高一致性级别，用户的应用程序会花更多时间等待在更改在RO的回放，可以在快速响应与一致性之间选择平衡。

图片

TencentDB  

04.下一步展望 

基于云基础设施构建云原生数据库

更彻底的云原生：全面拥抱云基础设施，目前TDSQL-C不管是计算还是存储节点多为物理机部署，正进行全面虚拟化，解决小地域开区物理限制等问题。

更极致的弹性：包括全栈Serverless及CPU/内存、存储解耦等，致力于提供更稳定、更优质的云数据服务。

以上内容来自冉仟元老师的分享。