騰訊云告訴你20分鐘能學到什么？下一代數(shù)據(jù)庫

炙手可熱的serverless架構，或者稱為無服務器架構，是最近幾年新冒出來的一種技術架構趨勢。

那么，被譽為云計算未來的serverless，有何優(yōu)勢？

在過去不久的全球分布式云大會上，騰訊云數(shù)據(jù)庫專家工程師李志陽分享了【分布式數(shù)據(jù)庫serverless化：深入解讀無服務器架構下的數(shù)據(jù)庫】的主題演講，給出了自己的答案。

Part1 serverless數(shù)據(jù)庫特點

隨著業(yè)務專注度的提升，服務的抽象程度也在提高。

李志陽舉了一個汽車服務的例子，以前為了出行只能購買汽車，現(xiàn)在可以使用打車服務，只需知道目的地即可，不再關注開車和保養(yǎng)，核心訴求得到了更好的滿足。

計算服務的演進也是類似，從前自建機房，需要維護機房設備；后來可以在云上直接購買虛擬機，部署業(yè)務，負責服務的擴縮容；現(xiàn)在的函數(shù)計算，從CI/CD到服務部署，擴縮容，全部自動完成，客戶可以更專注于業(yè)務代碼。

狹義的serverless分為FaaS和BaaS，基本特點是無需運維、以API方式提供服務、按實際使用計費、無使用無費用等。舉個例子，用戶瀏覽網(wǎng)頁，可能涉及CDN資源。如果是靜態(tài)內(nèi)容，從對象存儲下載照片、視頻；如果是動態(tài)內(nèi)容，則觸發(fā)一個函數(shù)計算，云函數(shù)將從云數(shù)據(jù)庫獲取相應的資源，生成用戶所需的動態(tài)內(nèi)容。其中，云函數(shù)為FaaS，對象存儲和云數(shù)據(jù)庫則為BaaS。

傳統(tǒng)的云數(shù)據(jù)庫會提供多種內(nèi)存/CPU規(guī)格給用戶購買。即使無法時刻用滿負載，用戶也需要為選中的規(guī)格付費。如果要將數(shù)據(jù)庫serverless化，需要滿足以下三大特性：

第一、自動擴縮容。訪問量上來時自動擴容，降低時自動縮容，用戶不需要關注規(guī)格。

第二、按照實際使用的資源付費。

第三、不使用不計費。如果沒有訪問，不應該收費。

Part2 serverless數(shù)據(jù)庫選型

在講述serverless數(shù)據(jù)庫選型之前，李志陽先介紹了云數(shù)據(jù)庫架構的演進。

圖左側是目前的主流架構—單體冗余架構（一主多從），是現(xiàn)在大部分客戶使用的架構。這類架構存在擴展性問題，實例的升降級和讀擴展，都通過數(shù)據(jù)搬遷實現(xiàn)，隨著數(shù)據(jù)量的增長，遷移耗時越來越長。

為了解決這個問題，業(yè)界趨勢是采用存算分離架構，衍生出兩類，一類是ShareNothing架構，計算和存儲均支持水平擴展，擴展能力非常強。不過，也存在一些缺點，其中最大的問題是SQL兼容性，解決之道在于持續(xù)構建和完善自己的生態(tài)，讓用戶更好的接受提供的用法。

另一類則是ShareStorage架構，共享存儲架構并沒有改變查詢引擎和ACI這些基礎特性，可以做到100%的兼容性。當然它也有缺點，目前計算節(jié)點沒有提供寫擴展能力，這個也是未來演進的方向。

隨后，李志陽又關注到了Serverless數(shù)據(jù)庫的用戶群，主要面向中長尾用戶，他們對擴展性的訴求并不強，更多關注使用的便利性，兼容性是最重要一點。

因此，騰訊云優(yōu)先選擇了基于共享存儲架構的數(shù)據(jù)庫產(chǎn)品TDSQL-C提供Serverless服務。

李志陽對TDSQL-C的總體架構進行了介紹：TDSQL-C是騰訊云基于共享存儲架構的云原生數(shù)據(jù)庫，始于2017年。由于ToB業(yè)務對穩(wěn)定性的要求很高，在設計之初就定下了一個基本原則，即復用云上的成熟組件。

在計算層使用了騰訊維護的MySQL內(nèi)核分支-TXSQL，復用它的bugfix和新特性；存儲側則選擇了在騰訊內(nèi)部有十幾年歷史的云硬盤CBS，把CBS的核心存儲和硬盤邏輯進行剖離，打造了統(tǒng)一存儲平臺-HiSTOR。

作為存儲底座，已適配了云硬盤CBS、云分布式文件系統(tǒng)CFS和數(shù)據(jù)庫TDSQL-C等多款產(chǎn)品，提供副本同步、故障自動遷移、數(shù)據(jù)校驗等一系列完善的數(shù)據(jù)安全保障能力，這正是TDSQL-C產(chǎn)品能夠穩(wěn)定運行數(shù)年的重要基石。

另外，它還提供豐富的特性：備份/回檔速度，支持以MB為粒度并發(fā)，速度達到GB/s；除了高性能的SSD，還有混存和EC版本，應對歸檔類的業(yè)務，提供更低成本的存儲。

除了上述兩個關鍵組件，我們還在計算側實現(xiàn)了物理復制，將innodb的redo日志準實時同步到備機，主從延時非常低（小于1毫秒）；相比傳統(tǒng)數(shù)據(jù)庫先寫日志后異步刷臟，TDSQL-C只寫日志到存儲，存儲側通過dbstore模塊將日志轉化數(shù)據(jù)。日志下沉的優(yōu)點很多，這里不做贅述。

由于騰訊云是國內(nèi)首家提供Serverless數(shù)據(jù)庫的廠家，李志陽主要對比了國外AWS的同類產(chǎn)品Aurora Serverless，并分析如何實現(xiàn)serverless數(shù)據(jù)庫的三大特性。

一、自動擴縮容：

上圖右側有一個共享的虛擬機池，規(guī)格不盡相同。Aurora Serverless的擴容策略是從1核2G到4核8G逐步遞增規(guī)格。例如需要從1核2G擴大到2核4G，則從池子里面找到2核4G的虛擬機，將對應的數(shù)據(jù)盤掛載到虛擬機，并將訪問切到該虛擬機，即可完成自動擴容。有2個問題：1、假設用戶訪問本身需要4核8G，Aurora Serverless仍需要從1核2G開始逐步增加到4核8G，擴容耗時偏長；2、由于選擇新的虛擬機擴容，會導致BP失效，訪問將經(jīng)歷一次冷啟動過程。

二、按使用量計費：

實現(xiàn)比較簡單，秒級粒度統(tǒng)計正在使用的規(guī)格，按照該規(guī)格計費。

三、不使用不計費：

如果實例超過一段時間沒有訪問，則關閉計算節(jié)點。由于有數(shù)據(jù)庫代理節(jié)點作為接入層，如果用戶再有訪問請求，會先到達數(shù)據(jù)庫代理節(jié)點。此時，代理節(jié)點按照上面提到的方法，從共享池里面找到對應的虛擬機提供服務。對用戶而言，原有連接不受到影響，只是感覺到一次卡頓。缺點是引入了代理節(jié)點，用戶需要為此付費；另外，恢復時長需要30秒，耗時也比較長。

（擴容時BP失效導致的問題）

Part3 TDSQL-C serverless

了解完業(yè)界情況，李志陽開始介紹TDSQL-C Serverless。

上圖為總體架構，核心模塊為中控節(jié)點（svls scheduler）。

中控節(jié)點接收計算層采集的內(nèi)存/CPU/訪問情況等監(jiān)控數(shù)據(jù)，根據(jù)策略決定是否擴縮容，啟停實例，以及按照計費規(guī)則上報云控制臺計費。

相對Aurora Serverless的區(qū)別在于暫停的應對，TDSQL-C Serverless有faker模塊，暫停計算節(jié)點時會把四層的vip:vport綁定到faker端口，用戶請求過來后，識別為有效的MySQL協(xié)議，則通知中控模塊將實例重新拉起。其優(yōu)點在于用戶不需要為代理節(jié)點付費。

隨后，李志陽詳細解釋了TDSQL-C Serverless如何滿足serverless數(shù)據(jù)庫的三大特性。

一、TDSQL-C Serverless的自動擴縮容：

目標是做到秒級的擴縮容，并且期間對用戶是平滑的，無感知的。

以上圖為例子，用戶在購買時選擇最小規(guī)格為1核2G，最大規(guī)格為2核4G。

左邊為Aurora Serverless，矩形的縱坐標是CPU，橫坐標為內(nèi)存。初始為1核2G，當業(yè)務訪問過來，把CPU用滿了，持續(xù)一段時間才擴容到2核4G。

而右側的TDSQL-C Serverless，初始就給用戶提供最大CPU規(guī)格，內(nèi)存則從最小規(guī)格開始。假設用戶使用的CPU超過1核，并持續(xù)一段時間，將把內(nèi)存從2G擴到4G。

可以看出，TDSQL-C Serverless的CPU資源不會受限，可以在設置的最大規(guī)格內(nèi)任意使用。優(yōu)點是用戶性能不受限，引入的缺點是可能整機出現(xiàn)滿負載。

由于TDSQL-C采用存算分離架構，一旦監(jiān)控到整機資源超過閾值，就進行快速遷移。遷移其實就是在另外一臺相對空閑的機器重新拉起實例，秒級完成。在資源負載上可以精準控制。

另外，現(xiàn)在云數(shù)據(jù)庫整機利用率偏低?；谶@兩點，TDSQL-C Serverless可以很好應對。

二、TDSQL-C Serverless的按使用量計費：

我們定義了一個算力單元CCU（TDSQL-C Compute Unit）=max{CPU,MEM/2,最小規(guī)格}。

其中，MEM/2的含義是，由于我們定義的規(guī)格CPU/內(nèi)存比都是1/2，內(nèi)存除以2相當于把內(nèi)存換算成CPU。整體還是以CPU決定整個算力。我們通過計算每個小時CCU平均值給用戶計費。

舉例說，假設用戶選擇最小最大規(guī)格為0.25核-4核，從圖中可以看到，業(yè)務高峰過來，一開始就能用到3核，右側CCU也會按照3核計費，能夠很好的應對業(yè)務負載。

三、TDSQL-C Serverless的不使用無計費：

自動啟停的邏輯比較簡單，只要10分鐘（用戶可配）內(nèi)監(jiān)測到?jīng)]有訪問就回收掉計算節(jié)點，訪問回來就把節(jié)點重新拉起。

這里最核心的點是怎么做到快速恢復，之前提過TDSQL-C是日志下沉的，存儲側接收到日志之后會源源不斷的回放，數(shù)據(jù)庫計算節(jié)點在啟動的過程中，不需要像傳統(tǒng)數(shù)據(jù)庫那樣加載到日志然后重放，所以啟動相對比較簡單和快速。

具體來說，VDL表示已經(jīng)持久化的日志點。在運行階段會不斷異步持久化VDL（last-vdl）。Recovery階段，首先獲取last-vdl（checkpoint點），然后廣播所有相關的小表獲取大于等于last-vdl的所有日志段，最后通過敗者樹找到最后連續(xù)的日志點作為VDL。

整個過程都是并行化的，而且沒有數(shù)據(jù)重放，耗時小于100毫秒。另外，我們還對MySQL啟動過程做了多處并行化處理，因此目前可以2秒內(nèi)恢復實例。

Part4展望

李志陽表示，TDSQL-C Serverless還在持續(xù)優(yōu)化，不久的將來會把冷啟動從2秒縮短到百毫秒級別，更貼近云函數(shù)的啟動時間。

同時，為了進一步降低用戶的存儲成本，如果很長時間沒有訪問，將數(shù)據(jù)轉存到對象存儲COS，屆時用戶只需要付COS的費用即可。