Serverless 數(shù)據(jù)庫

隨著業(yè)務的專注度越來越高，抽象的程度也越來越高，李志陽以汽車作為 Serverless 的類比，我們以前去購買一輛汽車，是為了開車去買車，現(xiàn)在可以租車、打車了，我們只需要知道目的地就行了，不需要關注過程，而是關注核心訴求。

在計算服務上面，演進也是類似的，我們從前是自建機房、維護整個機房；到后來在云上購買虛擬機部署業(yè)務，去負責里面的擴縮容；再到后來的函數(shù)計算，我們只需要關注業(yè)務帶，整個 CICD 到部署擴容這些東西完全不用關注，整個業(yè)界的抽象程度會越來越高。

狹義的 Serverless 分為 FAAS 和 BAAS 兩個方面，其基本特點是無需運維、主要以 API 的方式提供服務、按實際使用計費或無使用無費用等。假如用戶去瀏覽網頁的時候可能會涉及 CDN 資源，CDN 資源里面如果是靜態(tài)內容，Serverless 就會通過對象存儲里面把照片和視頻拉取出來，如果是動態(tài)的內容就會觸發(fā)一個函數(shù)計算，函數(shù)計算里面再去相應的云數(shù)據(jù)庫里面拉取相應的資源，生成用戶所要的動態(tài)內容。

如果要將數(shù)據(jù)庫 Serverless 化，傳統(tǒng)數(shù)據(jù)庫是怎么樣的呢？內存 CPU 是一個固定規(guī)格，用戶會選擇規(guī)格去購買，磁盤相對靈活，支持一定步長設置上限，以月預付的方式付費。Serverless 的特點，第一，自動擴縮容，用戶不需要關注它的規(guī)格，當訪問量上來的時候能夠自動擴，當訪問量下來的時候自動縮，不需要關注規(guī)格。第二，按照實際使用去付費。第三，不使用則不計費，存儲方面，如果我計數(shù)據(jù)的存儲只需要按實際的存儲去計費，如果不使用，這些計算的資源其實不應該去收費。

Serverless 數(shù)據(jù)庫選型

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

左邊是現(xiàn)在主流的架構——單體冗余架構，俗稱一主多從，是現(xiàn)在絕大部分用戶會使用的一種架構。這種架構的問題是什么呢？就是它的擴展性，不管是做實際的升降級，還是做擴展，都是需要數(shù)據(jù)搬遷去實現(xiàn)，隨著用戶量越來越大，搬遷的時間會越來越長。

為了解決這個問題，業(yè)界整體趨勢是存算分離，計算和存儲分離開獨自擴展。延伸出來有兩類，一個是 ShareNothing 架構，支持水平擴展，它的擴展能力非常強，這是它的最大優(yōu)勢；也存在部分缺點，其中最重要的是它是自研產品，存在 SQL 兼容性的問題，需要構建自己的生態(tài)，讓用戶進到相應生態(tài)里面使用，這它一直在努力的方向。另外一種是 SharedStorage 共享存儲的架構，共享存儲的架構里并沒有改變查詢引擎和 ACI 這些基礎特性，整個兼容性可以做到 100%，完全兼容 MySQL。但它也有個缺點，就是只做了存儲的池化，所以它的計算節(jié)點目前來說寫還是沒有辦法擴展的，這個也是未來演進的方向。

隨后，李志陽又關注到了 Serverless 數(shù)據(jù)庫的用戶群，主要面向中長尾用戶，他們對于擴展性的訴求并不強，更多的關注使用的便利。兼容性是最重要的一個點，所以我們決定優(yōu)先去做 Serverless 化，會選擇 SharedStorage 的方式去做。

李志陽對 TDSQL-C 的總體架構進行了介紹，TDSQL-C 是騰訊云共享存儲數(shù)據(jù)庫，于 2017 年開始研發(fā)，在一開始就定下了一個基本原則，即復用云上的成熟組件。在計算層使用騰訊維護的 TXSQL，復用它的 bugfix 和新的特性；存儲側選擇在騰訊內部有十幾年歷史的云硬盤 CBS，把 CBS 的存儲部分和硬盤部分進行剖離，打造了 HiSTOR 存儲平臺，支持云硬盤、云間系統(tǒng)和數(shù)據(jù)庫，數(shù)據(jù)安全完全由 HiSTOR 去保證，它的副本同步、故障自動遷移、數(shù)據(jù)校驗平臺都有一個完整的團隊去支撐，這是產品能夠完整對外售賣的重要基礎。另外，它有很強的特性，比如它的備份/回檔速度非常快，快照以 MB 粒度并發(fā)，可以達到 GB/s 級的速度。另外，提供 SSD 的場景之外，還有混存和 EC 版本，可以應對歸檔類的業(yè)務，提供更低成本的存儲。

基于上述兩個存儲組件，在計算側實現(xiàn)物質復制，使用 dbstore 做數(shù)據(jù)同步，實時生成并實時同步到備機，延時非常低，小于 1 毫秒。同時做日志下沉，傳統(tǒng)的數(shù)據(jù)庫先寫日志異步，TDSQL-C 對存儲只會寫日志，通過后端 dbstore 的模塊去將日志轉化數(shù)據(jù)，日志下沉有非常多的優(yōu)點這里不做贅述。

騰訊云是國內首家提供 Serverless 數(shù)據(jù)庫的廠家，當時參考了國外 AWS 的 Aurora Serverless，它的三大特性是怎么實現(xiàn)的？

最右邊是有一個共享的虛擬池，規(guī)格不盡相同，當它擴容的時候是從 1 核 2G 到 4 核 8G 遞增式的擴容，比如從 1 核 2G 擴大到 2 核 4G 里面就去一個池子里面找到 2 核 4G 的虛擬機將它掛載在虛擬機里面自動服務就可以提供自動擴容了。這里面有一個問題，假設用戶訪問過來本身需要 4 核 8G，他仍然需要 1 核 2G 一直遞增到 4 核 8G，這個擴容的過程會相對慢一點。另外一個點，他每次去擴容的時候會選擇一個新的虛擬機，所以說它的 BP 會失效，每次擴容的時候用戶這邊會有一次冷啟動的過程。

按使用量計費做法比較簡單，使用哪一個規(guī)格就按照那個規(guī)格計費就可以了。不使用不計費，最短是 5 分鐘，上面有一個代理節(jié)點，知道用戶有訪問之后會按照剛才的方法共享池子里面找虛擬機拉起來業(yè)務的訪問，對業(yè)務來說就是一個卡頓，但是他的鏈接是不會有影響的。優(yōu)點說清楚了，但是它的缺點是什么呢？因為有代理節(jié)點，用戶需要為這個代理節(jié)點去付費，整個恢復時長可能 30 秒，耗時相對比較長。

擴容時BP失效導致的問題

TDSQL-C Serverless

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

整體架構方面，核心的模塊就是 svls scheduler。中控節(jié)點做決策，要不要去擴縮容，按照計費的規(guī)則上傳到云控制臺那邊去進行計費。這里相對于 Aurora Serverless 的區(qū)別在于暫停的應對，TDSQL-C Serverless 有 faker 模塊，當用戶上這個計算節(jié)點的時候會把四層的 vip pod 綁定到 faker 端口，用戶過來可以識別出來是協(xié)議把它拉起，其優(yōu)點在于用戶不需要為代理節(jié)點付費。

整體架構介紹完以后，李志陽介紹了 TDSQL-C Serverless 在實現(xiàn)三大特性方面的能力。

從自動擴縮容來看，我們希望做到秒級的擴縮容，這個期間用戶是無感知的，很平滑的。用戶購買時會選擇最小和最大規(guī)格，從 0.25 核開始到 4 核 8G，用戶可以選擇最小最大規(guī)格。

右邊的例子可以看到，如果用戶選擇最小是 1 核，最大是 2 核的情況下，在這邊 Amazon Aurzora 是怎么做的呢？當業(yè)務訪問過來的時候，縱坐標是 CPU，已經把 CPU1 核占滿了，持續(xù)一段時間會擴大到 2 核 4G。TDSQL-C Serverless 是一上來就會給用戶最大的規(guī)格，它的 CPU 資源是不會受限的，內存里面是從最小規(guī)格開始，假設用戶的 CPU 超過了 1 核，一段時間之后就會把他的內存從 2G 擴到 4G，但是他的 CPU 資源不會受限，可以在設置的最大規(guī)格上任意使用他的 CPU 資源。

TDSQL-C Serverless 的優(yōu)點是性能不受限，但是缺點是整機給他最大的資源規(guī)格，整機容易出現(xiàn)滿負載的情況，因為我們 TDSQL-C 是做計算存儲分離的，一旦監(jiān)控整機的資源超過一定的比例之后，就會去做快速的遷移，遷移的概念就是在另外一個機組拉起這個實例就 OK 了，這個速度可以做到秒級，在資源整體的負載上面可以控制的比較精準。現(xiàn)在云數(shù)據(jù)庫里面普遍的情況是 CPU 整機使用率都是相對偏低的，基于這兩個 TDSQL-C Serverless 去做這個應對。

按使用量計費上面我們希望是秒級粒度，我們定義了一個算力單元，CPU 和內存指定的最小規(guī)格，規(guī)格都是 CPU 和內存比都是 1：2，內存除以 2 可以把它換算成 CPU，整體還是以 CPU 決定整個算力的。我們就通過每個小時 CCU 的值平均給用戶進行計費。

李志陽舉例說，用戶假設選擇 0.25 核到 4 核之間，可以看到整個表格 CCU 的計算。右邊這邊可以看到，如果業(yè)務的峰值過來，一開始會用到 3 核的時候，右邊圖里面可以直接上到 3 核的 CPU，那么就按照 3 核 CPU 的 CCU 去計費，很好的應對整個業(yè)務的負載。

最后一部分就是說不使用無計費，里面很核心的點是怎么做到快速恢復，自動啟停的邏輯也是比較簡單，只要 10 分鐘內監(jiān)測到沒有用戶訪問就回收掉，業(yè)務訪問回來的時候就把節(jié)點拉起。這里面核心的點是怎么快速的拉起，之前提過做日志下沉很大的好處，后端接收到日志之后會源源不斷的回放，整個數(shù)據(jù)庫在計算節(jié)點啟動的過程不需要像傳統(tǒng)數(shù)據(jù)庫一樣加載到日志然后回放，沒有這個過程，所以啟動相對比較簡單。VDL 是日志已經持久化的日志點，小于 VDL 的話所有的日志多已經持久化了，在運行階段把日志下放推行 VDL，同時把 VDL 具體值存儲到后端。Recovery 階段，第一個從后端獲取 last-vdl，廣播所有相關的小表獲取，會找到最后的一個連續(xù)的 vdl 點作為日志恢復的點，就可以把這個實例拉起來，整個過程都是并行化的，也沒有數(shù)據(jù)存放的過程，時間可以小于 100 毫秒。另外，我們也做了對整個 MySQL 的啟動過程做了瀕行數(shù)據(jù)化，現(xiàn)在能做到 2 秒內就能恢復這個實例。

總結與展望

李志陽表示，后續(xù) TDSQL-C Serverless 會將冷啟動從 2 秒縮到 200 毫秒，貼近云函數(shù)的時間做冷啟動優(yōu)化，整體思路跟 Aurora 相似，以共享池子在線掛載存儲，減少進程啟動時間。

另外，在進一步降低用戶的存儲成本方面正在考慮的優(yōu)化方案，如果很長時間沒有訪問之后，將用戶的數(shù)據(jù)轉存到對象存儲里面，用戶只需要付對象存儲的費用就可以了。

總結

以上是生活随笔為你收集整理的深入解读无服务器架构下的数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。