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