當(dāng)前位置：首頁(yè) > 运维知识 > 数据库 >内容正文

数据库

一个数据库存储架构的独白

發(fā)布時(shí)間：2025/5/22 数据库 32 豆豆

生活随笔收集整理的這篇文章主要介紹了一个数据库存储架构的独白小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

本文由云+社區(qū)發(fā)表

本文作者：許中清，騰訊云自研數(shù)據(jù)庫(kù)CynosDB的分布式存儲(chǔ)CynosStore負(fù)責(zé)人。從事數(shù)據(jù)庫(kù)內(nèi)核開發(fā)、數(shù)據(jù)庫(kù)產(chǎn)品架構(gòu)和規(guī)劃。曾就職于華為，2015年加入騰訊，參與過(guò)TBase（PGXZ）、CynosDB等數(shù)據(jù)庫(kù)產(chǎn)品研發(fā)。專注于關(guān)系數(shù)據(jù)庫(kù)、數(shù)據(jù)庫(kù)集群、新型數(shù)據(jù)庫(kù)架構(gòu)等領(lǐng)域。目前擔(dān)任CynosDB的分布式存儲(chǔ)CynosStore負(fù)責(zé)人。

企業(yè)IT系統(tǒng)遷移到公有云上已然是正在發(fā)生的趨勢(shì)。數(shù)據(jù)庫(kù)服務(wù)，作為公有云上提供的關(guān)鍵組件，是企業(yè)客戶是否愿意將自己運(yùn)行多年的系統(tǒng)搬到云上的關(guān)鍵考量之一。另一方面，自從System R開始，關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)已經(jīng)大約四十年的歷史了。尤其是隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)實(shí)例的吞吐量要求越來(lái)越高。對(duì)于很多業(yè)務(wù)來(lái)說(shuō)，單個(gè)物理機(jī)器所能提供的最大吞吐量已經(jīng)不能滿足業(yè)務(wù)的高速發(fā)展。因此，數(shù)據(jù)庫(kù)集群是很多IT系統(tǒng)繞不過(guò)去的坎。

CynosDB for PostgreSQL是騰訊云自研的一款云原生數(shù)據(jù)庫(kù)，其主要核心思想來(lái)自于亞馬遜的云數(shù)據(jù)庫(kù)服務(wù)Aurora。這種核心思想就是“基于日志的存儲(chǔ)”和“存儲(chǔ)計(jì)算分離”。同時(shí)，CynosDB在架構(gòu)和工程實(shí)現(xiàn)上確實(shí)有很多和Aurora不一樣的地方。CynosDB相比傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)，主要解決如下問(wèn)題：

存算分離

存算分離是云數(shù)據(jù)庫(kù)區(qū)別于傳統(tǒng)數(shù)據(jù)庫(kù)的主要特點(diǎn)之一，主要是為了1）提升資源利用效率，用戶用多少資源就給多少資源；2）計(jì)算節(jié)點(diǎn)無(wú)狀態(tài)更有利于數(shù)據(jù)庫(kù)服務(wù)的高可用性和集群管理（故障恢復(fù)、實(shí)例遷移）的便利性。

存儲(chǔ)自動(dòng)擴(kuò)縮容

傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)會(huì)受到單個(gè)物理機(jī)器資源的限制，包括單機(jī)上存儲(chǔ)空間的限制和計(jì)算能力的限制。CynosDB采用分布式存儲(chǔ)來(lái)突破單機(jī)存儲(chǔ)限制。另外，存儲(chǔ)支持多副本，通過(guò)RAFT協(xié)議來(lái)保證多副本的一致性。

更高的網(wǎng)絡(luò)利用率

通過(guò)基于日志的存儲(chǔ)設(shè)計(jì)思路，大幅度降低數(shù)據(jù)庫(kù)運(yùn)行過(guò)程中的網(wǎng)絡(luò)流量。

更高的吞吐量

傳統(tǒng)的數(shù)據(jù)庫(kù)集群，面臨的一個(gè)關(guān)鍵問(wèn)題是：分布式事務(wù)和集群吞吐量線性擴(kuò)展的矛盾。也就是說(shuō)，很多數(shù)據(jù)庫(kù)集群，要么支持完整的ACID，要么追求極好的線性擴(kuò)展性，大部分時(shí)候魚和熊掌不可兼得。前者比如Oracle RAC，是目前市場(chǎng)上最成熟最完善的數(shù)據(jù)庫(kù)集群，提供對(duì)業(yè)務(wù)完全透明的數(shù)據(jù)訪問(wèn)服務(wù)。但是Oracle RAC的線性擴(kuò)展性卻被市場(chǎng)證明還不夠，因此，更多用戶主要用RAC來(lái)構(gòu)建高可用集群，而不是高擴(kuò)展的集群。后者比如Proxy+開源DB的數(shù)據(jù)庫(kù)集群方案，通常能提供很好的線性擴(kuò)展性，但是因?yàn)椴恢С址植际绞聞?wù)，對(duì)數(shù)據(jù)庫(kù)用戶存在較大的限制。又或者可以支持分布式事務(wù)，但是當(dāng)跨節(jié)點(diǎn)寫入比例很大時(shí)，反過(guò)來(lái)降低了線性擴(kuò)展能力。CynosDB通過(guò)采用一寫多讀的方式，利用只讀節(jié)點(diǎn)的線性擴(kuò)展來(lái)提升整個(gè)系統(tǒng)的最大吞吐量，對(duì)于絕大部份公有云用戶來(lái)說(shuō)，這就已經(jīng)足夠了。

存儲(chǔ)自動(dòng)擴(kuò)縮容

更高的網(wǎng)絡(luò)利用率

通過(guò)基于日志的存儲(chǔ)設(shè)計(jì)思路，大幅度降低數(shù)據(jù)庫(kù)運(yùn)行過(guò)程中的網(wǎng)絡(luò)流量。

更高的吞吐量

下圖為CynosDB for PostgreSQL的產(chǎn)品架構(gòu)圖，CynosDB是一個(gè)基于共享存儲(chǔ)、支持一寫多讀的數(shù)據(jù)庫(kù)集群。

CynosDB for PostgreSQL產(chǎn)品架構(gòu)圖

圖一CynosDB for PostgreSQL產(chǎn)品架構(gòu)圖

CynosDB基于CynosStore之上，CynosStore是一個(gè)分布式存儲(chǔ)，為CynosDB提供堅(jiān)實(shí)的底座。CynosStore由多個(gè)Store Node和CynosStore Client組成。CynosStore Client以二進(jìn)制包的形式與DB（PostgreSQL）一起編譯，為DB提供訪問(wèn)接口，以及負(fù)責(zé)主從DB之間的日志流傳輸。除此之外，每個(gè)Store Node會(huì)自動(dòng)將數(shù)據(jù)和日志持續(xù)地備份到騰訊云對(duì)象存儲(chǔ)服務(wù)COS上，用來(lái)實(shí)現(xiàn)PITR（即時(shí)恢復(fù)）功能。

一、CynosStore數(shù)據(jù)組織形式

CynosStore會(huì)為每一個(gè)數(shù)據(jù)庫(kù)分配一段存儲(chǔ)空間，我們稱之為Pool，一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)Pool。數(shù)據(jù)庫(kù)存儲(chǔ)空間的擴(kuò)縮容是通過(guò)Pool的擴(kuò)縮容來(lái)實(shí)現(xiàn)的。一個(gè)Pool會(huì)分成多個(gè)Segment Group（SG），每個(gè)SG固定大小為10G。我們也把每個(gè)SG叫做一個(gè)邏輯分片。一個(gè)Segment Group（SG）由多個(gè)物理的Segment組成，一個(gè)Segment對(duì)應(yīng)一個(gè)物理副本，多個(gè)副本通過(guò)RAFT協(xié)議來(lái)實(shí)現(xiàn)一致性。Segment是CynosStore中最小的數(shù)據(jù)遷移和備份單位。每個(gè)SG保存屬于它的數(shù)據(jù)以及對(duì)這部分?jǐn)?shù)據(jù)最近一段時(shí)間的寫日志。

CynosStore 數(shù)據(jù)組織形式

圖二 CynosStore 數(shù)據(jù)組織形式

圖二中CynosStore一共有3個(gè)Store Node，CynosStore中創(chuàng)建了一個(gè)Pool，這個(gè)Pool由3個(gè)SG組成，每個(gè)SG有3個(gè)副本。CynosStore還有空閑的副本，可以用來(lái)給當(dāng)前Pool擴(kuò)容，也可以創(chuàng)建另一個(gè)Pool，將這空閑的3個(gè)Segment組成一個(gè)SG并分配個(gè)這個(gè)新的Pool。

二、基于日志異步寫的分布式存儲(chǔ)

傳統(tǒng)的數(shù)據(jù)通常采用WAL（日志先寫）來(lái)實(shí)現(xiàn)事務(wù)和故障恢復(fù)。這樣做最直觀的好處是1）數(shù)據(jù)庫(kù)down機(jī)后可以根據(jù)持久化的WAL來(lái)恢復(fù)數(shù)據(jù)頁(yè)。2）先寫日志，而不是直接寫數(shù)據(jù)，可以在數(shù)據(jù)庫(kù)寫操作的關(guān)鍵路徑上將隨機(jī)IO（寫數(shù)據(jù)頁(yè)）變成順序IO（寫日志），便于提升數(shù)據(jù)庫(kù)性能。

基于日志的存儲(chǔ)

圖三基于日志的存儲(chǔ)

圖三（左）極度抽象地描述了傳統(tǒng)數(shù)據(jù)庫(kù)寫數(shù)據(jù)的過(guò)程：每次修改數(shù)據(jù)的時(shí)候，必須保證日志先持久化之后才可以對(duì)數(shù)據(jù)頁(yè)進(jìn)行持久化。觸發(fā)日志持久化的時(shí)機(jī)通常有

1）事務(wù)提交時(shí)，這個(gè)事務(wù)產(chǎn)生的最大日志點(diǎn)之前的所有日志必須持久化之后才能返回給客戶端事務(wù)提交成功；

2）當(dāng)日志緩存空間不夠用時(shí)，必須持久化之后才能釋放日志緩存空間；

3）當(dāng)數(shù)據(jù)頁(yè)緩存空間不夠用時(shí)，必須淘汰部分?jǐn)?shù)據(jù)頁(yè)來(lái)釋放緩存空間。比如根據(jù)淘汰算法必須要淘汰臟頁(yè)A，那么最后修改A的日志點(diǎn)之前的所有日志必須先持久化，然后才可以持久化A到存儲(chǔ)，最后才能真正從數(shù)據(jù)緩存空間中將A淘汰。

從理論上來(lái)說(shuō)，數(shù)據(jù)庫(kù)只需要持久化日志就可以了。因?yàn)橹灰獡碛袕臄?shù)據(jù)庫(kù)初始化時(shí)刻到當(dāng)前的所有日志，數(shù)據(jù)庫(kù)就能恢復(fù)出當(dāng)前任何一個(gè)數(shù)據(jù)頁(yè)的內(nèi)容。也就是說(shuō)，數(shù)據(jù)庫(kù)只需要寫日志，而不需要寫數(shù)據(jù)頁(yè)，就能保證數(shù)據(jù)的完整性和正確性。但是，實(shí)際上數(shù)據(jù)庫(kù)實(shí)現(xiàn)者不會(huì)這么做，因?yàn)?）從頭到尾遍歷日志恢復(fù)出每個(gè)數(shù)據(jù)頁(yè)將是非常耗時(shí)的；2）全量日志比數(shù)據(jù)本身規(guī)模要大得多，需要更多的磁盤空間去存儲(chǔ)。

那么，如果持久化日志的存儲(chǔ)設(shè)備不僅僅具有存儲(chǔ)能力，還擁有計(jì)算能力，能夠自行將日志重放到最新的頁(yè)的話，將會(huì)怎么樣？是的，如果這樣的話，數(shù)據(jù)庫(kù)引擎就沒(méi)有必要將數(shù)據(jù)頁(yè)傳遞給存儲(chǔ)了，因?yàn)榇鎯?chǔ)可以自行計(jì)算出新頁(yè)并持久化。這就是CynosDB“采用基于日志的存儲(chǔ)”的核心思想。圖三（右）極度抽象地描述了這種思想。圖中計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)置于不同的物理機(jī)，存儲(chǔ)節(jié)點(diǎn)除了持久化日志以外，還具備通過(guò)apply日志生成最新數(shù)據(jù)頁(yè)面的能力。如此一來(lái)，計(jì)算節(jié)點(diǎn)只需要寫日志到存儲(chǔ)節(jié)點(diǎn)即可，而不需要再將數(shù)據(jù)頁(yè)傳遞給存儲(chǔ)節(jié)點(diǎn)。

下圖描述了采用基于日志存儲(chǔ)的CynosStore的結(jié)構(gòu)。

基于日志的存儲(chǔ)

圖四 CynosStore：基于日志的存儲(chǔ)

此圖描述了數(shù)據(jù)庫(kù)引擎如何訪問(wèn)CynosStore。數(shù)據(jù)庫(kù)引擎通過(guò)CynosStore Client來(lái)訪問(wèn)CynosStore。最核心的兩個(gè)操作包括1）寫日志；2）讀數(shù)據(jù)頁(yè)。

數(shù)據(jù)庫(kù)引擎將數(shù)據(jù)庫(kù)日志傳遞給CynosStore，CynosStore Client負(fù)責(zé)將數(shù)據(jù)庫(kù)日志轉(zhuǎn)換成CynosStore Journal，并且負(fù)責(zé)將這些并發(fā)寫入的Journal進(jìn)行序列化，最后根據(jù)Journal修改的數(shù)據(jù)頁(yè)路由到不同的SG上去，并發(fā)送給SG所屬Store Node。另外，CynosStore Client采用異步的方式監(jiān)聽(tīng)各個(gè)Store Node的日志持久化確認(rèn)消息，并將歸并之后的最新的持久化日志點(diǎn)告訴數(shù)據(jù)庫(kù)引擎。

當(dāng)數(shù)據(jù)庫(kù)引擎訪問(wèn)的數(shù)據(jù)頁(yè)在緩存中不命中時(shí)，需要向CynosStore讀取需要的頁(yè)（read block）。read block是同步操作。并且，CynosStore支持一定時(shí)間范圍的多版本頁(yè)讀取。因?yàn)楦鱾€(gè)Store Node在重放日志時(shí)的步調(diào)不能完全做到一致，總會(huì)有先有后，因此需要讀請(qǐng)求發(fā)起者提供一致性點(diǎn)來(lái)保證數(shù)據(jù)庫(kù)引擎所要求的一致性，或者默認(rèn)情況下由CynosStore用最新的一致性點(diǎn)（讀點(diǎn)）去讀數(shù)據(jù)頁(yè)。另外，在一寫多讀的場(chǎng)景下，只讀數(shù)據(jù)庫(kù)實(shí)例也需要用到CynosStore提供的多版本特性。

CynosStore提供兩個(gè)層面的訪問(wèn)接口：一個(gè)是塊設(shè)備層面的接口，另一個(gè)是基于塊設(shè)備的文件系統(tǒng)層面的接口。分別叫做CynosBS和CynosFS，他們都采用這種異步寫日志、同步讀數(shù)據(jù)的接口形式。那么，CynosDB for PostgreSQL，采用基于日志的存儲(chǔ)，相比一主多從PostgreSQL集群來(lái)說(shuō)，到底能帶來(lái)哪些好處？

1）減少網(wǎng)絡(luò)流量。首先，只要存算分離就避免不了計(jì)算節(jié)點(diǎn)向存儲(chǔ)節(jié)點(diǎn)發(fā)送數(shù)據(jù)。如果我們還是使用傳統(tǒng)數(shù)據(jù)庫(kù)+網(wǎng)絡(luò)硬盤的方式來(lái)做存算分離（計(jì)算和存儲(chǔ)介質(zhì)的分離），那么網(wǎng)絡(luò)中除了需要傳遞日志以外，還需要傳遞數(shù)據(jù)，傳遞數(shù)據(jù)的大小由并發(fā)寫入量、數(shù)據(jù)庫(kù)緩存大小、以及checkpoint頻率來(lái)決定。以CynosStore作為底座的CynosDB只需要將日志傳遞給CynosStore就可以了，降低網(wǎng)絡(luò)流量。

2）更加有利于基于共享存儲(chǔ)的集群的實(shí)現(xiàn)：一個(gè)數(shù)據(jù)庫(kù)的多個(gè)實(shí)例（一寫多讀）訪問(wèn)同一個(gè)Pool。基于日志寫的CynosStore能夠保證只要DB主節(jié)點(diǎn)（讀寫節(jié)點(diǎn)）寫入日志到CynosStore，就能讓從節(jié)點(diǎn)（只讀節(jié)點(diǎn)）能夠讀到被這部分日志修改過(guò)的數(shù)據(jù)頁(yè)最新版本，而不需要等待主節(jié)點(diǎn)通過(guò)checkpoint等操作將數(shù)據(jù)頁(yè)持久化到存儲(chǔ)才能讓讀節(jié)點(diǎn)見(jiàn)到最新數(shù)據(jù)頁(yè)。這樣能夠大大降低主從數(shù)據(jù)庫(kù)實(shí)例之間的延時(shí)。不然，從節(jié)點(diǎn)需要等待主節(jié)點(diǎn)將數(shù)據(jù)頁(yè)持久化之后（checkpoint）才能推進(jìn)讀點(diǎn)。如果這樣，對(duì)于主節(jié)點(diǎn)來(lái)說(shuō)，checkpoint的間隔太久的話，就會(huì)導(dǎo)致主從延時(shí)加大，如果checkpoint間隔太小，又會(huì)導(dǎo)致主節(jié)點(diǎn)寫數(shù)據(jù)的網(wǎng)絡(luò)流量增大。

當(dāng)然，apply日志之后的新數(shù)據(jù)頁(yè)的持久化，這部分工作總是要做的，不會(huì)憑空消失，只是從數(shù)據(jù)庫(kù)引擎下移到了CynosStore。但是正如前文所述，除了降低不必要的網(wǎng)絡(luò)流量以外，CynosStore的各個(gè)SG是并行來(lái)做redo和持久化的。并且一個(gè)Pool的SG數(shù)量可以按需擴(kuò)展，SG的宿主Store Node可以動(dòng)態(tài)調(diào)度，因此可以用非常靈活和高效的方式來(lái)完成這部分工作。

三、CynosStore Journal（CSJ）

CynosStore Journal（CSJ）完成類似數(shù)據(jù)庫(kù)日志的功能，比如PostgreSQL的WAL。CSJ與PostgreSQL WAL不同的地方在于：CSJ擁有自己的日志格式，與數(shù)據(jù)庫(kù)語(yǔ)義解耦合。PostgreSQL WAL只有PostgreSQL引擎可以生成和解析，也就是說(shuō)，當(dāng)其他存儲(chǔ)引擎拿到PostgreSQL WAL片段和這部分片段所修改的基礎(chǔ)頁(yè)內(nèi)容，也沒(méi)有辦法恢復(fù)出最新的頁(yè)內(nèi)容。CSJ致力于定義一種與各種存儲(chǔ)引擎邏輯無(wú)關(guān)的日志格式，便于建立一個(gè)通用的基于日志的分布式存儲(chǔ)系統(tǒng)。CSJ定了5種Journal類型：

1.SetByte：用Journal中的內(nèi)容覆蓋指定數(shù)據(jù)頁(yè)中、指定偏移位置、指定長(zhǎng)度的連續(xù)存儲(chǔ)空間。

\2. SetBit：與SetByte類似，不同的是SetBit的最小粒度是Bit，例如PostgreSQL中hitbit信息，可以轉(zhuǎn)換成SetBit日志。

\3. ClearPage：當(dāng)新分配Page時(shí)，需要將其初始化，此時(shí)新分配頁(yè)的原始內(nèi)容并不重要，因此不需要將其從物理設(shè)備中讀出來(lái)，而僅僅需要用一個(gè)全零頁(yè)寫入即可，ClearPage就是描述這種修改的日志類型。

\4. DataMove：有一些寫入操作將頁(yè)面中一部分的內(nèi)容移動(dòng)到另一個(gè)地方，DataMove類型的日志用來(lái)描述這種操作。比如PostgreSQL在Vacuum過(guò)程中對(duì)Page進(jìn)行compact操作，此時(shí)用DataMove比用SetByte日志量更小。

\5. UserDefined：數(shù)據(jù)庫(kù)引擎總會(huì)有一些操作并不會(huì)修改某個(gè)具體的頁(yè)面內(nèi)容，但是需要存放在日志中。比如PostgreSQL的最新的事務(wù)id（xid）就是存儲(chǔ)在WAL中，便于數(shù)據(jù)庫(kù)故障恢復(fù)時(shí)知道從那個(gè)xid開始分配。這種類型日志跟數(shù)據(jù)庫(kù)引擎語(yǔ)義相關(guān)，不需要CynosStore去理解，但是又需要日志將其持久化。UserDefined就是來(lái)描述這種日志的。CynosStore針對(duì)這種日志只負(fù)責(zé)持久化和提供查詢接口，apply CSJ時(shí)會(huì)忽略它。

以上5種類型的Journal是存儲(chǔ)最底層的日志，只要對(duì)數(shù)據(jù)的寫是基于塊/頁(yè)的，都可以轉(zhuǎn)換成這5種日志來(lái)描述。當(dāng)然，也有一些引擎不太適合轉(zhuǎn)換成這種最底層的日志格式，比如基于LSM的存儲(chǔ)引擎。

CSJ的另一個(gè)特點(diǎn)是亂序持久化，因?yàn)橐粋€(gè)Pool的CSJ會(huì)路由到多個(gè)SG上，并且采用異步寫入的方式。而每個(gè)SG返回的journal ack并不同步，并且相互穿插，因此CynosStore Client還需要將這些ack進(jìn)行歸并并推進(jìn)連續(xù)CSJ點(diǎn)（VDL）。

CynosStore日志路由和亂序ACK

圖五 CynosStore日志路由和亂序ACK

只要是連續(xù)日志根據(jù)數(shù)據(jù)分片路由，就會(huì)有日志亂序ack的問(wèn)題，從而必須對(duì)日志ack進(jìn)行歸并。Aurora有這個(gè)機(jī)制，CynosDB同樣有。為了便于理解，我們對(duì)Journal中的各個(gè)關(guān)鍵點(diǎn)的命名采用跟Aurora同樣的方式。

這里需要重點(diǎn)描述的是MTR，MTR是CynosStore提供的原子寫單位，CSJ就是由一個(gè)MTR緊挨著一個(gè)MTR組成的，任意一個(gè)日志必須屬于一個(gè)MTR，一個(gè)MTR中的多條日志很有可能屬于不同的SG。針對(duì)PostgreSQL引擎，可以近似理解為：一個(gè)XLogRecord對(duì)應(yīng)一個(gè)MTR，一個(gè)數(shù)據(jù)庫(kù)事務(wù)的日志由一個(gè)或者多個(gè)MTR組成，多個(gè)數(shù)據(jù)庫(kù)并發(fā)事務(wù)的MTR可以相互穿插。但是CynosStore并不理解和感知數(shù)據(jù)庫(kù)引擎的事務(wù)邏輯，而只理解MTR。發(fā)送給CynosStore的讀請(qǐng)求所提供的讀點(diǎn)必須不能在一個(gè)MTR的內(nèi)部某個(gè)日志點(diǎn)。簡(jiǎn)而言之，MTR就是CynosStore的事務(wù)。

四、故障恢復(fù)

當(dāng)主實(shí)例發(fā)生故障后，有可能這個(gè)主實(shí)例上Pool中各個(gè)SG持久化的日志點(diǎn)在全局范圍內(nèi)并不連續(xù)，或者說(shuō)有空洞。而這些空洞所對(duì)應(yīng)的日志內(nèi)容已經(jīng)無(wú)從得知。比如有3條連續(xù)的日志j1, j2, j3分別路由到三個(gè)SG上，分別為sg1, sg2, sg3。在發(fā)生故障的那一刻，j1和j3已經(jīng)成功發(fā)送到sg1和sg3。但是j2還在CynosStore Client所在機(jī)器的網(wǎng)絡(luò)緩沖區(qū)中，并且隨著主實(shí)例故障而丟失。那么當(dāng)新的主實(shí)例啟動(dòng)后，這個(gè)Pool上就會(huì)有不連續(xù)的日志j1, j3，而j2已經(jīng)丟失。

當(dāng)這種故障場(chǎng)景發(fā)生后，新啟動(dòng)的主實(shí)例將會(huì)根據(jù)上次持久化的連續(xù)日志VDL，在每個(gè)SG上查詢自從這個(gè)VDL之后的所有日志，并將這些日志進(jìn)行歸并，計(jì)算出新的連續(xù)持久化的日志號(hào)VDL。這就是新的一致性點(diǎn)。新實(shí)例通過(guò)CynosStore提供的Truncate接口將每個(gè)SG上大于VDL的日志truncate掉，那么新實(shí)例產(chǎn)生的第一條journal將從這個(gè)新的VDL的下一條開始。

故障恢復(fù)時(shí)日志恢復(fù)過(guò)程

圖六：故障恢復(fù)時(shí)日志恢復(fù)過(guò)程

如果圖五剛好是某個(gè)數(shù)據(jù)庫(kù)實(shí)例故障發(fā)生的時(shí)間點(diǎn)，當(dāng)重新啟動(dòng)一個(gè)數(shù)據(jù)庫(kù)讀寫實(shí)例之后，圖六就是計(jì)算新的一致性點(diǎn)的過(guò)程。CynosStore Client會(huì)計(jì)算得出新的一致性點(diǎn)就是8，并且把大于8的日志都Truncate掉。也就是把SG2上的9和10truncate掉。下一個(gè)產(chǎn)生的日志將會(huì)從9開始。

五、多副本一致性

CynosStore采用Multi-RAFT來(lái)實(shí)現(xiàn)SG的多副本一致性， CynosStore采用批量和異步流水線的方式來(lái)提升RAFT的吞吐量。我們采用CynosStore自定義的benchmark測(cè)得單個(gè)SG上日志持久化的吞吐量為375萬(wàn)條/每秒。CynosStore benchmark采用異步寫入日志的方式測(cè)試CynosStore的吞吐量，日志類型包含SetByte和SetBit兩種，寫日志線程持續(xù)不斷地寫入日志，監(jiān)聽(tīng)線程負(fù)責(zé)處理ack回包并推進(jìn)VDL，然后benchmark測(cè)量單位時(shí)間內(nèi)VDL的推進(jìn)速度。375萬(wàn)條/秒意味著每秒鐘一個(gè)SG持久化375萬(wàn)條SetByte和SetBit日志。在一個(gè)SG的場(chǎng)景下，CynosStore Client到Store Node的平均網(wǎng)絡(luò)流量171MB/每秒，這也是一個(gè)Leader到一個(gè)Follower的網(wǎng)絡(luò)流量。

六、一寫多讀

CynosDB基于共享存儲(chǔ)CynosStore，提供對(duì)同一個(gè)Pool上的一寫多讀數(shù)據(jù)庫(kù)實(shí)例的支持，以提升數(shù)據(jù)庫(kù)的吞吐量。基于共享存儲(chǔ)的一寫多讀需要解決兩個(gè)問(wèn)題：

\1. 主節(jié)點(diǎn)（讀寫節(jié)點(diǎn)）如何將對(duì)頁(yè)的修改通知給從節(jié)點(diǎn)（只讀節(jié)點(diǎn)）。因?yàn)閺墓?jié)點(diǎn)也是有Buffer的，當(dāng)從節(jié)點(diǎn)緩存的頁(yè)面在主節(jié)點(diǎn)中被修改時(shí)，從節(jié)點(diǎn)需要一種機(jī)制來(lái)得知這個(gè)被修改的消息，從而在從節(jié)點(diǎn)Buffer中更新這個(gè)修改或者從CynosStore中重讀這個(gè)頁(yè)的新版本。

\2. 從節(jié)點(diǎn)上的讀請(qǐng)求如何讀到數(shù)據(jù)庫(kù)的一致性的快照。開源PostgreSQL的主備模式中，備機(jī)通過(guò)利用主機(jī)同步過(guò)來(lái)的快照信息和事務(wù)信息構(gòu)造一個(gè)快照（活動(dòng)事務(wù)列表）。CynosDB的從節(jié)點(diǎn)除了需要數(shù)據(jù)庫(kù)快照（活動(dòng)事務(wù)列表）以外，還需要一個(gè)CynosStore的快照（一致性讀點(diǎn)）。因?yàn)榉制娜罩緯r(shí)并行apply的。

如果一個(gè)一寫多讀的共享存儲(chǔ)數(shù)據(jù)庫(kù)集群的存儲(chǔ)本身不具備日志重做的能力，主從內(nèi)存頁(yè)的同步有兩種備選方案：

第一種備選方案，主從之間只同步日志。從實(shí)例將至少需要保留主實(shí)例自從上次checkpoint以來(lái)所有產(chǎn)生的日志，一旦從實(shí)例產(chǎn)生cache miss，只能從存儲(chǔ)上讀取上次checkpoint的base頁(yè)，并在此基礎(chǔ)上重放日志緩存中自上次checkpoint以來(lái)的所有關(guān)于這個(gè)頁(yè)的修改。這種方法的關(guān)鍵問(wèn)題在于如果主實(shí)例checkpoint之間的時(shí)間間隔太長(zhǎng)，或者日志量太大，會(huì)導(dǎo)致從實(shí)例在命中率不高的情況下在apply日志上耗費(fèi)非常多的時(shí)間。甚至，極端場(chǎng)景下，導(dǎo)致從實(shí)例對(duì)同一個(gè)頁(yè)會(huì)反復(fù)多次apply同一段日志，除了大幅增大查詢時(shí)延，還產(chǎn)生了很多沒(méi)必要的CPU開銷，同時(shí)也會(huì)導(dǎo)致主從之間的延時(shí)有可能大幅增加。

第二種備選方案，主實(shí)例向從實(shí)例提供讀取內(nèi)存緩沖區(qū)數(shù)據(jù)頁(yè)的服務(wù)，主實(shí)例定期將被修改的頁(yè)號(hào)和日志同步給從實(shí)例。當(dāng)讀頁(yè)時(shí)，從實(shí)例首先根據(jù)主實(shí)例同步的被修改的頁(yè)號(hào)信息來(lái)判斷是1）直接使用從實(shí)例自己的內(nèi)存頁(yè)，還是2）根據(jù)內(nèi)存頁(yè)和日志重放新的內(nèi)存頁(yè)，還是3）從主實(shí)例拉取最新的內(nèi)存頁(yè)，還是4）從存儲(chǔ)讀取頁(yè)。這種方法有點(diǎn)類似Oracle RAC的簡(jiǎn)化版。這種方案要解決兩個(gè)關(guān)鍵問(wèn)題：1）不同的從實(shí)例從主實(shí)例獲取的頁(yè)可能是不同版本，主實(shí)例內(nèi)存頁(yè)服務(wù)有可能需要提供多版本的能力。2）讀內(nèi)存頁(yè)服務(wù)可能對(duì)主實(shí)例產(chǎn)生較大負(fù)擔(dān)，因?yàn)槌硕鄠€(gè)從實(shí)例的影響以外，還有一點(diǎn)就是每次主實(shí)例中的某個(gè)頁(yè)哪怕修改很小的一部分內(nèi)容，從實(shí)例如果讀到此頁(yè)則必須拉取整頁(yè)內(nèi)容。大致來(lái)說(shuō)，主實(shí)例修改越頻繁，從實(shí)例拉取也會(huì)更頻繁。

相比較來(lái)說(shuō)，CynosStore也需要同步臟頁(yè)，但是CynosStore的從實(shí)例獲取新頁(yè)的方式要靈活的多有兩種選擇1）從日志重放內(nèi)存頁(yè)；2）從StoreNode讀取。從實(shí)例對(duì)同步臟頁(yè)需要的最小信息僅僅是到底哪些頁(yè)被主實(shí)例給修改過(guò)，主從同步日志內(nèi)容是為了讓從實(shí)例加速，以及降低Store Node的負(fù)擔(dān)。

CynosDB一寫多讀

圖七 CynosDB一寫多讀

圖七描述了一寫一讀（一主一從）的基本框架，一寫多讀（一主多從）就是一寫一讀的疊加。CynosStore Client（CSClient）運(yùn)行態(tài)區(qū)分主從，主CSClient源源不斷地將CynosStore Journal（CSJ）從主實(shí)例發(fā)送到從實(shí)例，與開源PostgreSQL主備模式不同的是，只要這些連續(xù)的日志到達(dá)從實(shí)例，不用等到這些日志全部apply，DB engine就可以讀到這些日志所修改的最新版本。從而降低主從之間的時(shí)延。這里體現(xiàn)“基于日志的存儲(chǔ)”的優(yōu)勢(shì)：只要主實(shí)例將日志持久化到Store Node，從實(shí)例即可讀到這些日志所修改的最新版本數(shù)據(jù)頁(yè)。

七、結(jié)語(yǔ)

CynosStore是一個(gè)完全從零打造、適應(yīng)云數(shù)據(jù)庫(kù)的分布式存儲(chǔ)。CynosStore在架構(gòu)上具備一些天然優(yōu)勢(shì)：1）存儲(chǔ)計(jì)算分離，并且把存儲(chǔ)計(jì)算的網(wǎng)絡(luò)流量降到最低； 2）提升資源利用率，降低云成本，3）更加有利于數(shù)據(jù)庫(kù)實(shí)例實(shí)現(xiàn)一寫多讀，4）相比一主兩從的傳統(tǒng)RDS集群具備更高的性能。除此之外，后續(xù)我們會(huì)在性能、高可用、資源隔離等方面對(duì)CynosStore進(jìn)行進(jìn)一步的增強(qiáng)。

此文已由作者授權(quán)騰訊云+社區(qū)發(fā)布

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的一个数据库存储架构的独白的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。