深入解讀無服務器架構下的數據庫
Serverless 數據庫
隨着業務的專注度越來越高，抽象的程度也越來越高，李志陽以汽車作爲 Serverless 的類比，我們以前去購買一輛汽車，是爲了開車去買車，現在可以租車、打車了，我們只需要知道目的地就行了，不需要關注過程，而是關注核心訴求。
在計算服務上面，演進也是類似的，我們從前是自建機房、維護整個機房；到後來在雲上購買虛擬機部署業務，去負責裏面的擴縮容；再到後來的函數計算，我們只需要關注業務帶，整個 CICD 到部署擴容這些東西完全不用關注，整個業界的抽象程度會越來越高。
狹義的 Serverless 分爲 FAAS 和 BAAS 兩個方面，其基本特點是無需運維、主要以 API 的方式提供服務、按實際使用計費或無使用無費用等。假如用戶去瀏覽網頁的時候可能會涉及 CDN 資源，CDN 資源裏面如果是靜態內容，Serverless 就會通過對象存儲裏面把照片和視頻拉取出來，如果是動態的內容就會觸發一個函數計算，函數計算裏面再去相應的雲數據庫裏面拉取相應的資源，生成用戶所要的動態內容。
如果要將數據庫 Serverless 化，傳統數據庫是怎麼樣的呢？內存 CPU 是一個固定規格，用戶會選擇規格去購買，磁盤相對靈活，支持一定步長設置上限，以月預付的方式付費。Serverless 的特點，第一，自動擴縮容，用戶不需要關注它的規格，當訪問量上來的時候能夠自動擴，當訪問量下來的時候自動縮，不需要關注規格。第二，按照實際使用去付費。第三，不使用則不計費，存儲方面，如果我計數據的存儲只需要按實際的存儲去計費，如果不使用，這些計算的資源其實不應該去收費。
Serverless 數據庫選型
在講述 Serverless 數據庫選型之前，李志陽先介紹了雲數據庫架構的演進。
左邊是現在主流的架構——單體冗餘架構，俗稱一主多從，是現在絕大部分用戶會使用的一種架構。這種架構的問題是什麼呢？就是它的擴展性，不管是做實際的升降級，還是做擴展，都是需要數據搬遷去實現，隨着用戶量越來越大，搬遷的時間會越來越長。
爲了解決這個問題，業界整體趨勢是存算分離，計算和存儲分離開獨自擴展。延伸出來有兩類，一個是 ShareNothing 架構，支持水平擴展，它的擴展能力非常強，這是它的最大優勢；也存在部分缺點，其中最重要的是它是自研產品，存在 SQL 兼容性的問題，需要構建自己的生態，讓用戶進到相應生態裏面使用，這它一直在努力的方向。另外一種是 SharedStorage 共享存儲的架構，共享存儲的架構裏並沒有改變查詢引擎和 ACI 這些基礎特性，整個兼容性可以做到 100%，完全兼容 MySQL。但它也有個缺點，就是隻做了存儲的池化，所以它的計算節點目前來說寫還是沒有辦法擴展的，這個也是未來演進的方向。
隨後，李志陽又關注到了 Serverless 數據庫的用戶羣，主要面向中長尾用戶，他們對於擴展性的訴求並不強，更多的關注使用的便利。兼容性是最重要的一個點，所以我們決定優先去做 Serverless 化，會選擇 SharedStorage 的方式去做。
李志陽對 TDSQL-C 的總體架構進行了介紹，TDSQL-C 是騰訊雲共享存儲數據庫，於 2017 年開始研發，在一開始就定下了一個基本原則，即複用雲上的成熟組件。在計算層使用騰訊維護的 TXSQL，複用它的 bugfix 和新的特性；存儲側選擇在騰訊內部有十幾年歷史的雲硬盤 CBS，把 CBS 的存儲部分和硬盤部分進行剖離，打造了 HiSTOR 存儲平臺，支持雲硬盤、雲間系統和數據庫，數據安全完全由 HiSTOR 去保證，它的副本同步、故障自動遷移、數據校驗平臺都有一個完整的團隊去支撐，這是產品能夠完整對外售賣的重要基礎。另外，它有很強的特性，比如它的備份 / 回檔速度非常快，快照以 MB 粒度併發，可以達到 GB/s 級的速度。另外，提供 SSD 的場景之外，還有混存和 EC 版本，可以應對歸檔類的業務，提供更低成本的存儲。
基於上述兩個存儲組件，在計算側實現物質複製，使用 dbstore 做數據同步，實時生成並實時同步到備機，延時非常低，小於 1 毫秒。同時做日誌下沉，傳統的數據庫先寫日誌異步，TDSQL-C 對存儲只會寫日誌，通過後端 dbstore 的模塊去將日誌轉化數據，日誌下沉有非常多的優點這裏不做贅述。
騰訊雲是國內首家提供 Serverless 數據庫的廠家，當時參考了國外 AWS 的 Aurora Serverless，它的三大特性是怎麼實現的？
最右邊是有一個共享的虛擬池，規格不盡相同，當它擴容的時候是從 1 核 2G 到 4 核 8G 遞增式的擴容，比如從 1 核 2G 擴大到 2 核 4G 裏面就去一個池子裏面找到 2 核 4G 的虛擬機將它掛載在虛擬機裏面自動服務就可以提供自動擴容了。這裏面有一個問題，假設用戶訪問過來本身需要 4 核 8G，他仍然需要 1 核 2G 一直遞增到 4 核 8G，這個擴容的過程會相對慢一點。另外一個點，他每次去擴容的時候會選擇一個新的虛擬機，所以說它的 BP 會失效，每次擴容的時候用戶這邊會有一次冷啓動的過程。
按使用量計費做法比較簡單，使用哪一個規格就按照那個規格計費就可以了。不使用不計費，最短是 5 分鐘，上面有一個代理節點，知道用戶有訪問之後會按照剛纔的方法共享池子裏面找虛擬機拉起來業務的訪問，對業務來說就是一個卡頓，但是他的鏈接是不會有影響的。優點說清楚了，但是它的缺點是什麼呢？因爲有代理節點，用戶需要爲這個代理節點去付費，整個恢復時長可能 30 秒，耗時相對比較長。
擴容時 BP 失效導致的問題
TDSQL-C Serverless
瞭解完業界情況之後，李志陽介紹了 TDSQL-C Serverless。
整體架構方面，核心的模塊就是 svls scheduler。中控節點做決策，要不要去擴縮容，按照計費的規則上傳到雲控制檯那邊去進行計費。這裏相對於 Aurora Serverless 的區別在於暫停的應對，TDSQL-C Serverless 有 faker 模塊，當用戶上這個計算節點的時候會把四層的 vip pod 綁定到 faker 端口，用戶過來可以識別出來是協議把它拉起，其優點在於用戶不需要爲代理節點付費。
整體架構介紹完以後，李志陽介紹了 TDSQL-C Serverless 在實現三大特性方面的能力。
從自動擴縮容來看，我們希望做到秒級的擴縮容，這個期間用戶是無感知的，很平滑的。用戶購買時會選擇最小和最大規格，從 0.25 核開始到 4 核 8G，用戶可以選擇最小最大規格。
右邊的例子可以看到，如果用戶選擇最小是 1 核，最大是 2 核的情況下，在這邊 Amazon Aurzora 是怎麼做的呢？當業務訪問過來的時候，縱座標是 CPU，已經把 CPU1 核佔滿了，持續一段時間會擴大到 2 核 4G。TDSQL-C Serverless 是一上來就會給用戶最大的規格，它的 CPU 資源是不會受限的，內存裏面是從最小規格開始，假設用戶的 CPU 超過了 1 核，一段時間之後就會把他的內存從 2G 擴到 4G，但是他的 CPU 資源不會受限，可以在設置的最大規格上任意使用他的 CPU 資源。
TDSQL-C Serverless 的優點是性能不受限，但是缺點是整機給他最大的資源規格，整機容易出現滿負載的情況，因爲我們 TDSQL-C 是做計算存儲分離的，一旦監控整機的資源超過一定的比例之後，就會去做快速的遷移，遷移的概念就是在另外一個機組拉起這個實例就 OK 了，這個速度可以做到秒級，在資源整體的負載上面可以控制的比較精準。現在雲數據庫裏面普遍的情況是 CPU 整機使用率都是相對偏低的，基於這兩個 TDSQL-C Serverless 去做這個應對。
按使用量計費上面我們希望是秒級粒度，我們定義了一個算力單元，CPU 和內存指定的最小規格，規格都是 CPU 和內存比都是 1：2，內存除以 2 可以把它換算成 CPU，整體還是以 CPU 決定整個算力的。我們就通過每個小時 CCU 的值平均給用戶進行計費。
李志陽舉例說，用戶假設選擇 0.25 核到 4 核之間，可以看到整個表格 CCU 的計算。右邊這邊可以看到，如果業務的峯值過來，一開始會用到 3 核的時候，右邊圖裏面可以直接上到 3 核的 CPU，那麼就按照 3 核 CPU 的 CCU 去計費，很好的應對整個業務的負載。
最後一部分就是說不使用無計費，裏面很核心的點是怎麼做到快速恢復，自動啓停的邏輯也是比較簡單，只要 10 分鐘內監測到沒有用戶訪問就回收掉，業務訪問回來的時候就把節點拉起。這裏面核心的點是怎麼快速的拉起，之前提過做日誌下沉很大的好處，後端接收到日誌之後會源源不斷的回放，整個數據庫在計算節點啓動的過程不需要像傳統數據庫一樣加載到日誌然後回放，沒有這個過程，所以啓動相對比較簡單。VDL 是日誌已經持久化的日誌點，小於 VDL 的話所有的日誌多已經持久化了，在運行階段把日誌下放推行 VDL，同時把 VDL 具體值存儲到後端。Recovery 階段，第一個從後端獲取 last-vdl，廣播所有相關的小表獲取，會找到最後的一個連續的 vdl 點作爲日誌恢復的點，就可以把這個實例拉起來，整個過程都是並行化的，也沒有數據存放的過程，時間可以小於 100 毫秒。另外，我們也做了對整個 MySQL 的啓動過程做了瀕行數據化，現在能做到 2 秒內就能恢復這個實例。
總結與展望
李志陽表示，後續 TDSQL-C Serverless 會將冷啓動從 2 秒縮到 200 毫秒，貼近雲函數的時間做冷啓動優化，整體思路跟 Aurora 相似，以共享池子在線掛載存儲，減少進程啓動時間。
另外，在進一步降低用戶的存儲成本方面正在考慮的優化方案，如果很長時間沒有訪問之後，將用戶的數據轉存到對象存儲裏面，用戶只需要付對象存儲的費用就可以了。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/_MfuhpSAtZFnB8p-xp5HUw