你聽過多少款無服務器架構（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，并保證實體在恢復時不影響資料的讀取，更大程度幫助用戶降低成本，

標籤：其他

上一篇：MySQL資料庫的性能分析 ---圖書《軟體性能測驗分析與調優實踐之路》-手稿節選

下一篇：旋轉門資料壓縮演算法在PostgreSQL中的實作 - 流式壓縮在物聯網、監控、傳感器等場景的應用