**| 导语 **TDSQL-C PostgreSQL(CynosDB)是腾讯云数据库团队自研的新一代云原生数据库，融合了传统数据库、云计算与新硬件技术的优势，采用计算和存储分离的架构，100%兼容 PostgreSQL，提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务。本文旨在从数据库内核的角度揭秘 TDSQL-C PostgreSQL 的核心架构与关键技术。本文适合读者：腾讯云售后服务，TDSQL-C 用户，TDSQL-C 开发者，需要有基本的数据库与存储知识。

一、概述

TDSQL-C 采用计算和存储分离的架构，所有计算节点共享一份数据，存储容量高达 128TB，单库最高可扩展至 16 节点，提供秒级的配置升降级、秒级的故障恢复和数据备份容灾服务。TDSQL-C 既融合了商业数据库稳定可靠、高性能、可扩展的特征，又具有开源云数据库简单开放、自我迭代的优势。TDSQL-C 不仅在性能、扩展性和高可用方面有大幅提升，计算存储的解耦使得计算层和存储层都获得了很大的独立优化空间，本文下面将介绍 TDSQL-C 架构的实现，以及在新架构上的关键技术优势。

二、TDSQL-C PostgreSQL(CynosDB) 架构

Primary Instance 是数据库的读写实例（RW），负责接收数据库的读写请求，Replica Instance 是数据库的只读实例（RO），负责处理数据库的只读请求，目前可以支持扩展最多 15 个 Replica 实例。

CynosFileSystem 是用户态分布式文件系统，主要提供分布式的文件管理，为 CynosPG 实例提供文件存储服务。CynosFS 是专为云原生数据库而打造的分布式用户态文件系统，将传统分布式文件系统优势与云原生数据库相关特征进行融合，是 TDSQL-C 弹性扩展、海量存储、高性价比的基石。

CynosStoreAgent、 CynosStoreMeta、CynosStoreNode 构成分布式云存储系统 CynosStore（一个支持日志的、提供多版本读的、分布式的块设备存储）。其中 CynosStoreNode 存储节点负责数据库的实际数据存储。同时 CynosStore 将日志实时同步到腾讯云冷存储（COS）上，用于基于时间点的数据备份与恢复服务。

**Primary Instance 和分布式存储之间传输的是日志流。**Primary Instance 将数据变更以日志的方式发送到 CynosStore 中，CynosStore 会定期的将日志合并到数据页面上，因此无需将脏页写到存储中，这是与传统数据库很大不同的地方。Replica Instance 没有写事务，因此，不会向 CynosStore 发送日志信息，但是会请求读取页面。Primary Instance 也会将日志同步到 Replica Instance 中，Replica Instance 会使用收到的日志更新内存中的数据页面，当 Replica Instance 切换成 Primary Instance 时，可以直接使用这些最新的页面对外提供服务，无需再次从 CynosStore 中读取页面。

**TDSQL-C 实现原理：**日志即数据库。基于此实现的数据库系统专为云原生而打造。数据库的 Primary Instance 会产生日志，并保存到 CynosStore 中，因此我们从存储上，针对于每一个数据页面，均可以拿到基于日志回放的任何时间的页面版本。也就是说，CynosStore 提供了一个基于页面的多版本存储系统，每一个版本都是基于一个或者多个 MTR 的回放（Mini-Transaction Record：多条日志的集合，用来保证数据库中的页面或者索引结构从一个“一致性”状态，到另一个“一致性状态”）。

1.计算层

数据库引擎 CynosPG 基于 PostgreSQL 而来，PostgreSQL 是世界上功能最强大最先进的开源数据库。经过长达 30 年以上的积极开发和不断演进，PostgreSQL 已在可靠性、稳定性、数据一致性等获得了业内极高的声誉。CynosPG 主要对 PostgreSQL 日志系统和存储系统进行改造，进行 Oracle 语法高度兼容，以及深度的内核性能及功能优化，对于 PostgreSQL SQL 引擎架构改动有限，因此 CynosPG 可以完全兼容 PostgreSQL 原生的功能。

分布式用户态文件系统 CynosFileSystem，为实例提供分布式的文件管理，负责将文件的读写请求翻译为对应的 BLOCK 读写，CynosFileSystem 为实例提供 Pool 维度的存储访问，如上图所示。

CynosStoreAgent 为 CynosFS 提供 SG 维度的存储访问，提供 SG 的读写接口，对于读写请求有不同处理。 写请求：将修改日志通过 LOG API 发送到 CynosStoreNode，读请求：直接通过 BLOCK API 读取 CynosStoreNode 数据。CynosStoreAgent 除了承担计算层与存储层的读写交互，也负责主备间日志流同步，对于 CynosPG 主备实例间只通过 CynosStoreAgent 进行交互。在工程实现上，由于现代多核和多插槽计算机对于跨核间的数据共享（atomic instruction、cache line bouncing、memory fences）代价非常大，CynosStoreAgent（无锁实现）工程实现上使用了创新的 share-nothing 编程异步框架，一种无需耗时锁定即可在 CPU 内核之间共享信息的设计，面向现代新硬件技术的优势实现了极致性能。

2.存储层

CynosStoreNode 以 Segment 为维度进行资源管理，Segment Group 内 3 个 Segment 实际存储同一份数据，通过一致性协议（Raft）进行同步。CynosStoreNode 负责 Segment 日志的处理、BLOCK 数据的异步回放、读请求的页面多版本支持等。同时还负责将日志备份到 Cold Backup Storage（COS），进行增量备份，根据增量备份，可以灵活的生成全量备份和差异备份。相比于传统的开源数据库，云原生数据库 TDSQL-C 计算层仍然包含传统内核的大部分组件（查询处理器、事务管理、锁、缓存实现以及 MVCC），但有几个重要核心功能（redo 日志记录、日志回放、持久存储、崩溃恢复和备份/恢复）均下沉到存储层。在工程实现上，CynosStoreNode（无锁实现）与 CynosStoreAgent 一样，使用了创新的 share-nothing 的编程异步框架，无共享模型的异步框架，结合现代新硬件技术，实现存储层的极致性能。

CynosStoreMeta 负责 CynosStore Service 资源的分配和调度，采用一主两从架构，包括 Pool 调度和 SG 调度、备份回档调度，以及维护 Pool 和 SG 的对应关系。 CynosStoreMeta 两类调度一个是资源池 Pool 调度（自动扩缩容 Pool），一个是 SegmentGroup 调度（增减副本，leader 切换，资源均衡等）。

三、TDSQL-C PostgreSQL(CynosDB) 技术优势

日志即数据库

TDSQL-C 引入计算存储分离的设计，存储层使用共享的分布式存储，计算层则将传统数据库不必要的 IO 全部卸载，如上图所示写 IO 只有 Redo 日志流，Redo 日志能表达数据库的所有状态，实现计算与存储基于日志传输的新数据库架构，真正实现了将 Redo LOG 下沉到存储层，将网络 IO 减少到最低。

TDSQL-C 计算层实现无状态，计算层本地数据文件将不复存在，仍然包含传统数据库内核的大部分组件：查询处理器、事务管理、锁、缓存实现以及 MVCC 多版本，移除了 PostgreSQL 中的 FPW 特性，脏页面刷盘操作。

TDSQL-C 存储层实现可计算智能存储，传统内核几个重要核心功能：Redo 日志记录、日志回放、持久存储、崩溃恢复和备份/恢复，均下沉到存储层，由分布式存储系统自动管理数据的多副本，实现自动扩缩容，自动故障校验检测和修复，同时实现了存储页面多版本支持。

计算与存储分离，共享分布式存储

采用计算与存储分离的设计理念，满足业务弹性扩展的需求。各计算节点通过用户态分布式文件系统（CynosFileSystem）共享底层的存储（CynosStore），极大降低了用户的存储成本。

一写多读，读写分离

TDSQL-C 采用多节点集群的架构，集群中有一个主节点（可读可写）和至少一个只读节点。当应用程序使用集群地址时，TDSQL-C 通过内部的代理层对外提供服务，应用程序的请求都先经过代理，然后才访问到数据库节点。代理层不仅可以做安全认证和保护，还可以解析 SQL，把写操作发送到主节点，把读操作均衡地分发到多个只读节点，实现自动的读写分离。对于应用程序来说，就像使用一个单点的数据库一样简单。

完全兼容

TDSQL-C 完全兼容 PostgreSQL，代码/应用无需修改或只需少量修改，业务无需改造即可平滑迁移。同时 TDSQL-C 会定期实现对 PostgreSQL 新版本的兼容性。可以使用 PostgreSQL 导入/导出工具或者快照，将 PostgreSQL 数据库轻松迁移到 TDSQL-C。

极致性能

深度定制的数据库内核，超高性能，可以满足高并发高性能的场景，保证关键业务的连续性，并可进一步提供读写分离以及读写扩展性。如在 CynosPG，CynosFileSystem 大量使用的异步、流水线、批处理、Lock Free 结构等等。

新硬件技术及零拷贝技术，减少操作系统上下文切换以及数据在用户态和内核态之间拷贝引起的性能损耗，进一步优化关键路径的系统性能。如 RDMA、NVME、SPDK 等等。

CynosStore 在工程实现上真正做到了无锁实现，创新的使用了 share-nothing 编程异步框架，无锁实现即可在 CPU 内核之间共享信息的设计，面向现代新硬件技术的优势实现了极致性能。

海量存储

最高 128TB 的海量存储，无服务器 Serverless 架构，自动扩缩容，自动故障检测修复，并按实际使用量计费，不用不计费，轻松应对业务数据量动态变化和持续增长。自动维护数据多个副本通过 Parallel-Raft 协议保证数据的一致性，保障数据安全可靠。同时不再需要因为单机容量的限制而去购买多个实例做分片，由此简化应用开发，降低运维负担。

秒级故障恢复、快速弹性变配、快速只读扩展

计算节点实现了无状态，支持秒级的故障切换和恢复，即便计算节点所在的物理机宕机也可以在 1 分钟之内恢复。

计算节点根据业务需要快速升降配，升降配不断连接，根据内存大小不同升降级时间最快可到秒级，实现计算资源的成本最优。

计算节点根据业务需要快速添加只读节点，一个集群支持秒级添加删除 1 个 - 15 个只读节点，快速应对业务峰值和变化场景。利用日志流 LSN 确保读取数据时的全局一致性，避免因为主备延迟引起的不一致。利用基于 Redo 的物理复制代替逻辑复制，提升主备复制的效率和稳定性。

快照备份回档

基于数据多版本的秒级快照备份对用户的数据进行连续备份保护，免去主从架构备份回档数据的同步和搬迁，最高以 GB/秒的速度极速并行回档，保证业务数据迅速恢复。整个备份回档流程无锁实现，对实例存储无任何影响。

四、总结

由于篇幅有限，具体实现细节并没有详细地阐述，本文主要全局的介绍了 TDSQL-C 核心架构与关键技术，后续文章会详细揭秘 TDSQL-C 各个内核组件具体实现细节。腾讯云数据库团队也在不断的探索更多的功能与优化，如在执行器优化器探索，向量化执行引擎，XRDMA 更低延迟 IO 栈，MTCP 面向多核的用户态网络协议栈，DB 语义下推与异构计算加速，FPGA 存储引擎加速，Hybrid Storage（Optane/DRAM/AEP/ScaleFlux）等等软硬一体化融合工作，去追求更佳的功能性能以及用户体验，后续我们也会尽量给大家分享这些细节的进展与实现。如果在使用 TDSQL-C 中遇到疑惑，不要犹豫请立刻联系我们，我们会努力地为大家答疑，感谢对 TDSQL-C 的支持。

五、相关概念

Segment（Seg）：Storage Service 管理数据 BLOCK 和日志的最小单元（10GB），也是数据复制的实体。图中同样颜色的 3 个 Segment 实际存储同一份数据，通过一致性协议（Raft）进行同步，我们叫做 Segment Group（SG）。

Pool：多个 Segment Group（SG）从逻辑上构成一个连续的存储数据 BLOCK 的块设备，供上层的 CynosFileSystem 分配使用。Pool 和 Segment 是一对多的关系。