20分钟能学到什么？下一代数据库-技术圈

炙手可热的serverless架构，或者称为无服务器架构，是最近几年新冒出来的一种技术架构趋势。

那么，被誉为云计算未来的serverless，有何优势？

在过去不久的全球分布式云大会上，腾讯云数据库专家工程师李志阳分享了【分布式数据库serverless化：深入解读无服务器架构下的数据库】的主题演讲，给出了自己的答案。

Part1 serverless数据库特点

随着业务专注度的提升，服务的抽象程度也在提高。

李志阳举了一个汽车服务的例子，以前为了出行只能购买汽车，现在可以使用打车服务，只需知道目的地即可，不再关注开车和保养，核心诉求得到了更好的满足。

计算服务的演进也是类似，从前自建机房，需要维护机房设备；后来可以在云上直接购买虚拟机，部署业务，负责服务的扩缩容；现在的函数计算，从CI/CD到服务部署，扩缩容，全部自动完成，客户可以更专注于业务代码。

狭义的serverless分为FaaS和BaaS，基本特点是无需运维、以API方式提供服务、按实际使用计费、无使用无费用等。举个例子，用户浏览网页，可能涉及CDN资源。如果是静态内容，从对象存储下载照片、视频；如果是动态内容，则触发一个函数计算，云函数将从云数据库获取相应的资源，生成用户所需的动态内容。其中，云函数为FaaS，对象存储和云数据库则为BaaS。

传统的云数据库会提供多种内存/CPU规格给用户购买。即使无法时刻用满负载，用户也需要为选中的规格付费。如果要将数据库serverless化，需要满足以下三大特性：

第一、自动扩缩容。访问量上来时自动扩容，降低时自动缩容，用户不需要关注规格。

第二、按照实际使用的资源付费。

第三、不使用不计费。如果没有访问，不应该收费。

Part2 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数据库的三大特性。

一、自动扩缩容：

上图右侧有一个共享的虚拟机池，规格不尽相同。Aurora Serverless的扩容策略是从1核2G到4核8G逐步递增规格。例如需要从1核2G扩大到2核4G，则从池子里面找到2核4G的虚拟机，将对应的数据盘挂载到虚拟机，并将访问切到该虚拟机，即可完成自动扩容。有2个问题：1、假设用户访问本身需要4核8G，Aurora Serverless仍需要从1核2G开始逐步增加到4核8G，扩容耗时偏长；2、由于选择新的虚拟机扩容，会导致BP失效，访问将经历一次冷启动过程。

二、按使用量计费

实现比较简单，秒级粒度统计正在使用的规格，按照该规格计费。

三、不使用不计费：

如果实例超过一段时间没有访问，则关闭计算节点。由于有数据库代理节点作为接入层，如果用户再有访问请求，会先到达数据库代理节点。此时，代理节点按照上面提到的方法，从共享池里面找到对应的虚拟机提供服务。对用户而言，原有连接不受到影响，只是感觉到一次卡顿。缺点是引入了代理节点，用户需要为此付费；另外，恢复时长需要30秒，耗时也比较长。