腾讯云原生数据库TDSQL-C架构探索和实践

作为云原生技术先驱，腾讯云数据库内核团队致力于不断提升产品的可用性、可靠性、性能和可扩展性，为用户提供更加极致的体验。为帮助用户了解极致体验背后的关键技术点，本期带来腾讯云数据库专家工程师王鲁俊给大家分享的腾讯云原生数据库TDSQL-C的架构探索和实践，内容主要分为四个部分：

本次分享主要分为四个部分： 第一部分，介绍腾讯云原生数据库 TDSQL-C 产品架构，包括产品的研发背景和架构主要特性； 第二部分，分享用户场景实践，针对线上真实的用户场景做一些分析和针对性实践； 第三部分，分享系统关键优化； 第四部分，分享产品未来演进。

点击此处观看完整视频

TDSQL-C 产品架构

背景

腾讯云原生数据库最初采用的是传统架构，也就是 MySQL 实例，或者说是采用 Binlog 复制的主备方式的架构。但这种架构在现有的一些用户需求来看是有很多问题的。

比如存储容量。传统架构实例的存储上限受限于本地磁盘上限，一般是几百 G，或者几个 T 的量级，做扩展的成本非常高而且麻烦。当用户数据非常多时，会做分库分表，使用现有的分库分表中间件或解决方案会带来一些分布式事务的问题。

做业务的同学知道，分布式事务处理起来会比较麻烦，涉及如何应对故障，如何应对分布式事务产生的数据不一致等问题。用户在存储容量方面的需求是实例容量大于 100T，并且存储容量能够快速透明的扩展。

其次是可靠性。传统架构基于 BinLog 复制，普通的异步或者半同步的复制方式可能会丢数据，同步的复制方式性能损失会比较大。用户在可靠性方面的需求是第一不能丢数据，即 RPO 等于 0；第二数据是有多副本容灾的，也就是要达到一定程度的数据可靠性。

此外还有可用性，可用性对于用户来讲就是服务有多长时间不可用，比如在传统架构发生一次 HA，或者宕机重启，这段时间服务都是不可用的。HA、恢复时间慢对用户来讲很难接受，传统架构 HA 或者副本的恢复速度可能达到了分钟级。第二个问题是基于 BinLog 复制的时候，主备副本的延迟比较高，有些可能达到分钟级，甚至达到小时级。用户希望能够快速切换 HA，实现秒级恢复，还包括回档功能，如果有副本，希望副本的延迟能够比较小，最好是秒级以下，甚至是毫秒级。

最后是可扩展性。传统架构的扩展性是非常复杂的，基于 Binlog 创建只读副本也会非常复杂，要先把原始的数据给复制过来，然后搭建主备同步，只读副本才能开始工作，这个过程至少是分钟级甚至是小时级别的。对用户来讲，他们希望当读需求有扩展性需求的时候，可以实现秒级的读副本扩展。

我们针对这四个方面的用户需求，采用了存储计算分离架构，这也是 TDSQL-C 所采纳的核心的架构想法。

简单来说，要解决存储容量和可靠性方面的问题，第一我们会用云存储，云存储之间是可以水平扩展的，理论上它的容量是无限的，而且对于每一份数据都有多副本来保证可靠性。数据分散在云存储的各个节点上，在这个基础上可以做持续备份，并行回档等功能。

在可用性方面，数据放在云存储上之后，数据的分片是可以做并行恢复的，回档也可以做并行回档。物理复制的时延一般会比基于 Binlog 的逻辑复制更低一点。

最后在可扩展性方面，共享存储的优势更加明显，当新建一个只读副本的时候，数据不需要复制一份出来，因为数据是在云存储上作为共享数据存在的，只需要把数据共享，另外再构建增量的数据复制就可以了。

架构特性

上面这张图是 TDSQL-C 的整体架构，从这个架构中我们可以看到，它整体上分为上一层的计算层和下一层的存储层。

计算层