TDSQL-C Serverless 服务是如何实现通过接入层来实现恢复感知

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

站在用户的角度考虑，谁都不希望数据库每次启停都耗费大量的时间，更不希望在这个过程中对业务有任何的影响。因此，极致压缩冷启动时间，做到链接不断转发请求的能力相当关键。为了实现这一能力，TDSQL-C 做了众多探索，最后选定了通过在接入层增加一个恢复感知器来实现秒级冷启动这一方案。同比于通过 proxy 来实现链接的保持和转发能力的方案，TDSQL-C采用的方案更加贴合 Serverless 服务为用户提供低成本的理念。这是因为采用 proxy 模式需要支付额外的成本，整体设计会更加复杂，并且还需要设计多租户的能力。

建连流程

这一方案的核心要点是在 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 进行相互的转发。

注意：

         目前腾讯云原生数据库TDSQL-C有新春特惠活动，新人1.88元起

测试一下

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

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

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

经过多轮测试，我们累加内核侧、管控侧、perceptron 侧的总体冷启动时间，整体重连时间约在 2000ms 左右。