TDSQL-C 真·秒级启停：连接断了，又没断( 二 ) _生活百科

文章插图
由于 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 实例，如果其在运行中我们也可以通过手动暂停来停止实例的运行。