TDSQL-C 真·秒級啟停：連接斷了，又沒斷
你聽過多少款無伺服器架構（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，並保證實例在恢復時不影響數據的讀取，更大程度幫助用戶降低成本。
