你听过多少款无服务器架构（Serverless）数据库？

什么是Serverless呢？简单理解，Serverless 分为 FaaS 和 BaaS 两个部分，其中 FaaS 指的是函数即服务，BaaS 是后端即服务。

举个例子，用户浏览网页，可能涉及CDN资源。如果是静态内容，从对象存储下载照片、视频；如果是动态内容，则触发一个函数计算，云函数将从云数据库获取相应的资源，生成用户所需的动态内容。其中，云函数为 FaaS，对象存储和云数据库则为 BaaS。

传统的云数据库会提供多种内存/CPU规格给用户购买。即使无法时刻用满负载，用户也需要为选中的规格付费。大多数客户在购买数据库服务时，只能根据历史经验来推测需求规格，无法准确判断业务未来的发展趋势。也是，咱们没有天眼，谁知道什么时候能被时代选中呢？

不过，咱还是要默默的问自己一声。万一爆红，你的数据库做好准备迎接业务访问量暴涨、计算或存储的需求量激增了吗？

不打算爆红的企业不是好企业，抱着一颗要爆红的心，大多数的企业会选择比真实需求稍微偏大一些规格的数据库服务。在没爆红前，这就是存储、计算资源的浪费，也是哗哗的银子在流淌。当然也有很多务实的企业，计算的近乎精准，可还是避免不了资源的灵活规划问题，如某一时刻突然业务访问量暴涨，对计算或存储的需求量激增，也容易出现实例资源不够、规格太小，需要紧急扩容。

那，用户当然要问了，到底我要选择多大规格的呢？在 TDSQL-C 这儿，完全不用纠结。

Serverless 服务是腾讯云数据库自研的新一代云原生关系型数据库 TDSQL-C MySQL版的无服务器、全 Serverless 架构版。TDSQL-C 推出的 Serverless 服务基于计算与存储分离的理念，满足了客户在公有云计算环境下根据业务发展弹性扩展集群的刚性需求，让用户不再纠结实例资源问题，让用户像使用自来水一样使用数据库。总结其特性，可分为以下三点：

• 自动扩缩容：用户不需要过度关注规格，访问量上来时自动扩容，降低时自动缩容，且实现扩缩容的过程中做到业务无感知；
• 实用实付：按秒计量，按小时结算，按照实际使用的资源付费；
• 不使用不计费：如果没有访问，不应该收费，帮助业务极大程度地节省成本；

要想完美的实现 Serverless 的特性，必然不能放过任何一个细节。数据库实例的启停过程带来的时间成本、安全挑战就是其中重要的一点，接下来将会围绕这个细节为大家阐述腾讯云数据库TDSQL-C的解法。

一、头脑风暴

在一些极限的测试场景下，实例会频繁的自动启停，这时候如何保证实例停止后快速恢复呢？如何保证在恢复实例时无需用户重复链接，直到恢复访问？

站在用户的角度考虑，谁都不希望数据库每次启停都耗费大量的时间，更不希望在这个过程中对业务有任何的影响。因此，极致压缩冷启动时间，做到链接不断转发请求的能力相当关键。

为了实现这一能力，我们做了众多探索，最后选定了通过在接入层增加一个恢复感知器来实现秒级冷启动这一方案。同比于通过 proxy 来实现链接的保持和转发能力的方案，我们采用的方案更加贴合 Serverless 服务为用户提供低成本的理念。这是因为采用 proxy 模式需要支付额外的成本，整体设计会更加复杂，并且还需要设计多租户的能力。

二、建连流程

接下来，我们将详细解读 TDSQL-C Serverless 服务是如何实现通过接入层来实现恢复感知服务这一方案的。

这一方案的核心要点是在 TDSQL-C 的接入层增加了一个恢复感知器（下文简称：perceptron），通过 perceptron 模块来实现请求转发，perceptron 在和客户端握手之后，不断开与用户连接，恢复实例后，与 TDSQL-C 握手，后续转发四层报文。以下为 perceptron 与 TDSQL-C 建连的具体过程：

在实例暂停的状态下，如果有连接发起时，MySQL 客户端首先会同 preceptron 进行 TCP 握手（P0）。

完成 TCP 握手之后，preceptron 会向客户端发送 “随机数 A” 进行挑战（P1），MySQL 客户端用自己的账号密码和 “随机数 A” 来计算并回复自己的 “登录解答 A”（P2）。

由于 preceptron 并没有存储用户的账号密码，所以无法校验 “登录解答 A” 是否正确，但 preceptron 能区分客户端是 MySQL 客户端，还是其他类型的客户端（preceptron 在机器学习界是分类器，区分不同类型的客户端，这也是我们以它命名的原因之一）。

校验 “登录解答 A” 将由 TDSQL-C 计算层（下文简称：TDSQL-C）来完成，preceptron 通过管控唤醒 TDSQL-C 后（P3），开始下一步的登录校验流程。

在和 preceptron TCP 握手之后（P4），对于 TDSQL-C 来说，preceptron 也是一个普通的 MySQL 客户端，所以也发送一个 “随机数 B” 挑战（P5）给 preceptron。

preceptron 的回复是一个我们实现的特殊的 MySQL 报文（P6），首先它用 “随机数 B” 和 preceptron 自身的鉴权机制计算得到 “登录解答 B” 并放入报文中，其次它也将 “随机数 A” 和 “登录解答 A” 捎带在此报文中。

TDSQL-C 收到特殊的解答报文后会做两次校验，第一次是 “随机数 B” 和 “登录解答 B” 的正确性以及 preceptron 的身份，通过后再进行第二次的 “随机数 A” 和 “登录解答 A” 的正确性，通过即以用户身份进行登录，并回复 preceptron 登录成功（P7）。

preceptron 进而回复用户登录成功（P8）。

经历过这样的流程后，我们在客户端发起一次登陆请求后，实例就可以完全无感地进行实例恢复，恢复登录后，后续的请求和数据包通过 preceptron 进行相互的转发。

比较巧妙的点在于整体流程设计采用了两个挑战随机数进行鉴权，这样做的优势在于：

• 实现中继模块 preceptron 不存储用户名密码的情况下也可以完成用户名密码验证；
• 保证了用户密码的安全性，也不会引入存储的密码不一致的问题；

由于后续的 SQL 请求都是通过 preceptron 进行转发，此功能对于 preceptron 的安全性、稳定性、低资源消耗以及低延迟响应能力都有要求。所以 TDSQL-C 团队采用了 Rust 语言进行研发，相比使用垃圾回收机制管理内存的语言，Rust 具有更稳定的响应时间。同时基于 Rust 内存管理特点，使得 preceptron 更安全，占用的内存资源更少，最大化降低成本。

至此，读者一定会疑问，基于 serverless 形态下如果所有请求都通过 preceptron 进行转发，这样成本和开销无疑会变大，有悖于数据库在 serverless 下的低成本特性吧？

其实，选择 serverless 的用户更在意低成本，而不是读写分离和链接保持能力。因此我们在设计 preceptron 模块时，只会把触发恢复的请求链接接路由到 preceptron 上，当实例恢复后，新增的请求会直接发给 TDSQL-C。

这一流程是通过 VIP 权重来实现路由的定向转发。当实例处于暂停状态时，仅保留 preceptron 的路由；当实例恢复后时，同时保留 preceptron 的路由和 TDSQL-C 的路由，并设置 preceptron 的路由权重为 0，以实现新增连接直连到 TDSQL-C，同时存量与 preceptron 已经建连的链接依然能够通讯。

三、测试一下

那么下面我们来模拟一下用户恢复实例的链接不断机制。首先我们选好一个暂停状态的 serverlss 实例，如果其在运行中我们也可以通过手动暂停来停止实例的运行。

通过监控数据和控制台，我们可以看到上面的实例已经处于完全暂停状态了，接下来我们通过远程连接工具，直接对数据库发起连接请求。

如下图所示，我们在发起数据库连接请求时，可以做到秒级数据库恢复，并且在整个连接的过程中用户侧对实例恢复和重连毫无感知，极大程度地提高了 Serverlss 产品的易用性。

经过多轮测试，我们累加内核侧、管控侧、perceptron 侧的总体冷启动时间，整体重连时间约在 2000ms 左右。浅放一张今天下午测试的结果，欢迎大家来体验秒级的快乐！

TDSQL-C Serverless 功能还在持续优化中，今天我们更贴近了云函数的启动时间，在保证实例暂停的状态下快速拉起服务并对业务无感。未来，我们还会继续提升冷启动的时间。

同时，我们为了进一步降低用户的存储成本，我们在持续探索新型的存储能力，在实例暂停状态下将数据转存到对象存储COS，并保证实例在恢复时不影响数据的读取，更大程度帮助用户降低成本。