全球分布式云联盟力求打造分布式云计算旗舰级技术盛会，本次大会共设有分布式云报告会、边缘计算论坛、Serverless云原生论坛、分布式数据库论坛、分布式存储论坛，跨境SD-WAN咨询会等六大论坛，围绕分布式云、分布式算力、Serverless、云原生、HTAP、IPFS等技术与实践展开。联合阿里云、腾讯云、百度云、金山云等全栈技术引领者与全球分布式云联盟携手打造这场技术饕餮盛宴。
01 Serverless数据库特点
计算服务的演进也是类似，从前自建机房，需要维护机房设备；后来可以在云上直接购买虚拟机，部署业务，负责服务的扩缩容；现在的函数计算，从CI/CD到服务部署，扩缩容，全部自动完成，客户可以更专注于业务代码。
狭义的serverless分为FaaS和BaaS，基本特点是无需运维、以API方式提供服务、按实际使用计费、无使用无费用等。
举个例子，用户浏览网页，可能涉及CDN资源。如果是静态内容，从对象存储下载照片、视频；如果是动态内容，则触发一个函数计算，云函数将从云数据库获取相应的资源，生成用户所需的动态内容。其中，云函数为FaaS，对象存储和云数据库则为BaaS。
传统的云数据库会提供多种内存/CPU规格给用户购买。即使无法时刻用满负载，用户也需要为选中的规格付费。如果要将数据库serverless化，需要满足以下三大特性：
第二、按照实际使用的资源付费。
第三、不使用不计费。如果没有访问，不应该收费。
图左侧是目前的主流架构—单体冗余架构（一主多从），是现在大部分客户使用的架构。这类架构存在扩展性问题，实例的升降级和读扩展，都通过数据搬迁实现，随着数据量的增长，迁移耗时越来越长。
为了解决这个问题，业界趋势是采用存算分离架构，衍生出两类，一类是ShareNothing架构，计算和存储均支持水平扩展，扩展能力非常强。不过，也存在一些缺点，其中最大的问题是SQL兼容性，解决之道在于持续构建和完善自己的生态，让用户更好的接受提供的用法；
另一类则是ShareStorage架构，共享存储架构并没有改变查询引擎和ACI这些基础特性，可以做到100%的兼容性。当然它也有缺点，目前计算节点没有提供写扩展能力，这个也是未来演进的方向。
随后，李志阳又关注到了Serverless数据库的用户群，主要面向中长尾用户，他们对扩展性的诉求并不强，更多关注使用的便利性，兼容性是最重要一点。
因此，腾讯云优先选择了基于共享存储架构的数据库产品TDSQL-C提供Serverless服务。
在计算层使用了腾讯维护的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秒，耗时也比较长。
扩容时BP失效导致的问题
上图为总体架构，核心模块为中控节点（svls scheduler）。
中控节点接收计算层采集的内存/CPU/访问情况等监控数据，根据策略决定是否扩缩容，启停实例，以及按照计费规则上报云控制台计费。
相对Aurora Serverless的区别在于暂停的应对，TDSQL-C Serverless有faker模块，暂停计算节点时会把四层的vip:vport绑定到faker端口，用户请求过来后，识别为有效的MySQL协议，则通知中控模块将实例重新拉起。其优点在于用户不需要为代理节点付费。
随后，李志阳详细解释了TDSQL-C Serverless如何满足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可以很好应对。
二、 按使用量计费：
我们定义了一个算力单元CCU（TDSQL-C Compute Unit）=max{CPU,MEM/2,最小规格}。其中，MEM/2的含义是，由于我们定义的规格CPU/内存比都是1/2，内存除以2相当于把内存换算成CPU。
整体还是以CPU决定整个算力。我们通过计算每个小时CCU平均值给用户计费。
举例说，假设用户选择最小最大规格为0.25核-4核，从图中可以看到，业务高峰过来，一开始就能用到3核，右侧CCU也会按照3核计费，能够很好的应对业务负载。
三、 不使用无计费：
自动启停的逻辑比较简单，只要10分钟（用户可配）内监测到没有访问就回收掉计算节点，访问回来就把节点重新拉起。
最核心的点是怎么做到快速恢复，之前提过TDSQL-C是日志下沉的，存储侧接收到日志之后会源源不断的回放，数据库计算节点在启动的过程中，不需要像传统数据库那样加载到日志然后重放，所以启动相对比较简单和快速。
具体来说，VDL表示已经持久化的日志点。在运行阶段会不断异步持久化VDL（last-vdl）。Recovery阶段，首先获取last-vdl（checkpoint点），然后广播所有相关的小表获取大于等于last-vdl的所有日志段，最后通过败者树找到最后连续的日志点作为VDL。整个过程都是并行化的，而且没有数据重放，耗时小于100毫秒。
另外，我们还对MySQL启动过程做了多处并行化处理，目前可以2秒内恢复实例。
同时，为了进一步降低用户的存储成本，如果很长时间没有访问，将数据转存到对象存储COS，届时用户只需要付COS的费用即可。最后，欢迎大家多多使用TDSQL-C Serverless！
