CynosDB技术详解——架构设计

CynosDB是新一代分布式数据库，兼容MySQL和PostgreSQL，支持存储弹性扩展，一主多从共享数据，性能更是超越社区原生MySQL和PostgreSQL。CynosDB采用share storage架构，其弹性扩展和高性价比的基石则是CynosDB File System（简称CynosFS）：一款腾讯云自研的用户态分布式文件系统。本文旨在从整体上讲述CynosDB和CynosFS的核心架构设计。

挑战与应对
CynosDB是公有云原生架构的，其核心思想是在资源池化的基础上实现公有云高性价比、高可用性以及弹性扩展等诸多优势。实现资源池化的大技术挑战是高效、稳定的弹性调度能力，该能力也是公有云产品高可用性的基石。计算、网络和存储是公有云三大类Iaas产品，前面两类都有比较成熟的弹性调度架构，唯独存储产品例外。究其根本还是数据调度的代价太高。数据库是典型的计算+存储的产品，要做到资源池化需要：

l存储与计算分离：这样计算资源（主要包含CPU和内存）就可以使用现有成熟的容器、虚拟机等技术实现资源池化

l分布式存储：将数据分割成规格化的块，引入分布式调度系统，实现存储容量和IO的弹性调度，从而实现存储资源的池化

那么对于数据库产品来说，是否有现成架构可以很好的满足以上两个需求呢。我们发现虚拟机+分布式块存储（云盘）的方案非常合适，目前主流公有云平台也都有非常成熟的产品。腾讯云今年早些时候推出的MySQL基础版以及AWS上的RDS都是基于这种架构。图1简单描述了这种架构：

图 1

但该架构有如下不足：

l网络IO重：可以看到就1个数据库实例，就有大量数据需要写到云盘，这些数据主要包括：WAL LOG、页数据、防止页部分写的Double Write或者Full Page Write。除此之外，云盘还要将这些数据做多个备份

l主从实例不共享数据：一方面浪费了大量存储，另一方面进一步加重了网络IO

这些不足导致基于该架构的数据库产品在系统吞吐能力上无法与基于物理机部署的主从架构竞争，而且延迟也受到很大的挑战，这对OLTP类业务的影响非常明显。同时每个数据库实例都单独拥有一份（实际可能是2-3份）存储，成本也很高。

CynosDB针对这两个不足，采用了如下设计：

l日志下沉： WAL LOG从逻辑上已经包含了数据的所有变动，CynosDB将WAL LOG下沉到存储层，数据库实例就只需要将WAL LOG写到存储层，不再需要写页数据（页数据以及Double Write或Full Page Write），同时这个WAL LOG也作为RAFT协议的日志来完成多个数据备份的同步，进一步减少了网络IO。

l主从实例共享数据：CynosDB的主从实例共享共一份存储数据，进一步减少了网络IO，同时极大的减少了存储容量

循着这两个解决思路，我们对传统基于云盘的架构进行优化，就有了CynosDB如下架构：