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 已经建连的链接依然能够通讯。