腾讯云李志阳：分布式数据库 Serverless 化
早在 2019 年，Serverless 就曾被 Gartner 称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路，被誉为云计算未来。
在全球分布式云大会上，腾讯云数据库专家工程师李志阳老师为大家带来了：《分布式数据库 Serverless化：深入解读无服务器架构下的数据库》的分享。
01.
Serverless 数据库特点
随着业务专注度的提升，服务的抽象程度也在提高。
李志阳举了一个汽车服务的例子，以前为了出行只能购买汽车，现在可以使用打车服务，只需知道目的地即可，不再关注开车和保养，核心诉求得到了更好的满足。
计算服务的演进也是类似，从前自建机房，需要维护机房设备；后来可以在云上直接购买虚拟机，部署业务，负责服务的扩缩容；现在的函数计算，从 CI/CD 到服务部署，扩缩容，全部自动完成，客户可以更专注于业务代码。
狭义的 Serverless 分为 FaaS 和 BaaS，基本特点是无需运维、以 API 方式提供服务、按实际使用计费、无使用无费用等。举个例子，用户浏览网页，可能涉及 CDN 资源。如果是静态内容，从对象存储下载照片、视频；如果是动态内容，则触发一个函数计算，云函数将从云数据库获取相应的资源，生成用户所需的动态内容。其中，云函数为 FaaS，对象存储和云数据库则为 BaaS。
传统的云数据库会提供多种内存 / CPU 规格给用户购买。即使无法时刻用满负载，用户也需要为选中的规格付费。如果要将数据库 Serverless 化，需要满足以下三大特性：
1. 自动扩缩容。访问量上来时自动扩容，降低时自动缩容，用户不需要关注规格。
2. 按照实际使用的资源付费。
3. 不使用不计费。如果没有访问，不应该收费。
02.
Serverless 数据库选型
在讲述 Serverless 数据库选型之前，李志阳先介绍了云数据库架构的演进。
图左侧是目前的主流架构—单体冗余架构（一主多从），是现在大部分客户使用的架构。这类架构存在扩展性问题，实例的升降级和读扩展，都通过数据搬迁实现，随着数据量的增长，迁移耗时越来越长。
为了解决这个问题，业界趋势是采用存算分离架构，衍生出两类，一类是 ShareNothing 架构，计算和存储均支持水平扩展，扩展能力非常强。不过，也存在一些缺点，其中最大的问题是 SQL 兼容性，解决之道在于持续构建和完善自己的生态，让用户更好的接受提供的用法。
另一类则是 ShareStorage 架构，共享存储架构并没有改变查询引擎和 ACI 这些基础特性，可以做到 100% 的兼容性。当然它也有缺点，目前计算节点没有提供写扩展能力，这个也是未来演进的方向。
随后，李志阳又关注到了 Serverless 数据库的用户群，主要面向中长尾用户，他们对扩展性的诉求并不强，更多关注使用的便利性，兼容性是最重要一点。
因此，腾讯云优先选择了基于共享存储架构的数据库产品 TDSQL-C 提供 Serverless 服务。
李志阳对 TDSQL-C 的总体架构进行了介绍：TDSQL-C 是腾讯云基于共享存储架构的云原生数据库，始于 2017 年。由于 ToB 业务对稳定性的要求很高，在设计之初就定下了一个基本原则，即复用云上的成熟组件。
在计算层使用了腾讯维护的 MySQL 内核分支-TXSQL，复用它的 bugfix 和新特性；存储侧则选择了在腾讯内部有十几年历史的云硬盘 CBS，把 CBS 的核心存储和硬盘逻辑进行剖离，打造了统一存储平台- HiSTOR。
作为存储底座，已适配了云硬盘 CBS、云分布式文件系统 CFS 和数据库 TDSQL-C 等多款产品，提供副本同步、故障自动迁移、数据校验等一系列完善的数据安全保障能力，这正是 TDSQL-C 产品能够稳定运行数年的重要基石。
另外，它还提供丰富的特性：备份 / 回档速度，支持以 MB 为粒度并发，速度达到 GB/s；除了高性能的 SSD，还有混存和 EC 版本，应对归档类的业务，提供更低成本的存储。
除了上述两个关键组件，我们还在计算侧实现了物理复制，将 innodb 的 redo 日志准实时同步到备机，主从延时非常低（小于 1 毫秒）；相比传统数据库先写日志后异步刷脏，TDSQL-C 只写日志到存储，存储侧通过 dbstore 模块将日志转化数据。日志下沉的优点很多，这里不做赘述。
由于腾讯云是国内首家提供 Serverless 数据库的厂家，李志阳主要对比了国外 AWS 的同类产品 Aurora Serverless，并分析如何实现 Serverless 数据库的三大特性。
1. 自动扩缩容
上图右侧有一个共享的虚拟机池，规格不尽相同。Aurora Serverless 的扩容策略是从 1 核 2G 到 4 核 8G 逐步递增规格。例如需要从 1 核 2G 扩大到 2 核 4G，则从池子里面找到 2 核 4G 的虚拟机，将对应的数据盘挂载到虚拟机，并将访问切到该虚拟机，即可完成自动扩容。
有 2 个问题：1、假设用户访问本身需要 4 核 8G，Aurora Serverless 仍需要从 1 核 2G 开始逐步增加到 4 核 8G，扩容耗时偏长；2、由于选择新的虚拟机扩容，会导致 BP 失效，访问将经历一次冷启动过程。
2. 按使用量计费
实现比较简单，秒级粒度统计正在使用的规格，按照该规格计费。
3. 不使用不计费
如果实例超过一段时间没有访问，则关闭计算节点。由于有数据库代理节点作为接入层，如果用户再有访问请求，会先到达数据库代理节点。此时，代理节点按照上面提到的方法，从共享池里面找到对应的虚拟机提供服务。对用户而言，原有连接不受到影响，只是感觉到一次卡顿。缺点是引入了代理节点，用户需要为此付费；另外，恢复时长需要 30 秒，耗时也比较长。
（扩容时BP失效导致的问题）
03.
TDSQL-C Serverless
了解完业界情况，李志阳开始介绍 TDSQL-C Serverless。
上图为总体架构，核心模块为中控节点（Svls Scheduler）。
中控节点接收计算层采集的内存 / CPU / 访问情况等监控数据，根据策略决定是否扩缩容，启停实例，以及按照计费规则上报云控制台计费。
相对 Aurora Serverless 的区别在于暂停的应对，TDSQL-C Serverless 有 Faker模块，暂停计算节点时会把四层的 vip:vport 绑定到 Faker 端口，用户请求过来后，识别为有效的 MySQL 协议，则通知中控模块将实例重新拉起。其优点在于用户不需要为代理节点付费。
随后，李志阳详细解释了 TDSQL-C Serverless如何满足Serverless 数据库的三大特性。
1. TDSQL-C Serverless 的自动扩缩容：
目标是做到秒级的扩缩容，并且期间对用户是平滑的，无感知的。
以上图为例子，用户在购买时选择最小规格为1核2G，最大规格为2核 4G。
左边为 Aurora Serverless，矩形的纵坐标是 CPU，横坐标为内存。初始为 1 核 2G，当业务访问过来，把 CPU 用满了，持续一段时间才扩容到 2 核 4G。
而右侧的 TDSQL-C Serverless，初始就给用户提供最大 CPU 规格，内存则从最小规格开始。假设用户使用的 CPU 超过 1 核，并持续一段时间，将把内存从 2G 扩到 4G。
可以看出，TDSQL-C Serverless 的 CPU 资源不会受限，可以在设置的最大规格内任意使用。优点是用户性能不受限，引入的缺点是可能整机出现满负载。
由于 TDSQL-C 采用存算分离架构，一旦监控到整机资源超过阈值，就进行快速迁移。迁移其实就是在另外一台相对空闲的机器重新拉起实例，秒级完成。在资源负载上可以精准控制。
另外，现在云数据库整机利用率偏低。基于这两点，TDSQL-C Serverless 可以很好应对。
2. TDSQL-C Serverless 的按使用量计费：
我们定义了一个算力单元 CCU（TDSQL-C Compute Unit）=max{CPU,MEM/2,最小规格}。
其中，MEM/2 的含义是，由于我们定义的规格 CPU/内存比都是 1/2，内存除以 2 相当于把内存换算成 CPU。整体还是以 CPU决定整个算力。我们通过计算每个小时 CCU 平均值给用户计费。
举例说，假设用户选择最小最大规格为 0.25 核 - 4 核，从图中可以看到，业务高峰过来，一开始就能用到 3 核，右侧 CCU 也会按照 3 核计费，能够很好的应对业务负载。
3. TDSQL-C Serverless 的不使用无计费
自动启停的逻辑比较简单，只要 10 分钟（用户可配）内监测到没有访问就回收掉计算节点，访问回来就把节点重新拉起。
这里最核心的点是怎么做到快速恢复，之前提过 TDSQL-C 是日志下沉的，存储侧接收到日志之后会源源不断的回放，数据库计算节点在启动的过程中，不需要像传统数据库那样加载到日志然后重放，所以启动相对比较简单和快速。
具体来说，VDL 表示已经持久化的日志点。在运行阶段会不断异步持久化 VDL（last-vdl）。Recovery 阶段，首先获取 last-vdl（checkpoint 点），然后广播所有相关的小表获取大于等于 last-vdl 的所有日志段，最后通过败者树找到最后连续的日志点作为 VDL。
整个过程都是并行化的，而且没有数据重放，耗时小于 100 毫秒。另外，我们还对 MySQL 启动过程做了多处并行化处理，因此目前可以 2 秒内恢复实例。
04.
展望
李志阳表示，TDSQL-C Serverless 还在持续优化，不久的将来会把冷启动从 2 秒缩短到百毫秒级别，更贴近云函数的启动时间。
同时，为了进一步降低用户的存储成本，如果很长时间没有访问，将数据转存到对象存储 COS，届时用户只需要付 COS 的费用即可。最后，欢迎大家多多使用TDSQL-C Serverless！
推荐阅读
GitHub: github.com/serverless 官网: cloud.tencent.com/product/serverless-catalog