腾讯云mysql架构_一个数据库存储架构的独白
本文由云+社區(qū)發(fā)表
本文作者：許中清，騰訊云自研數(shù)據(jù)庫CynosDB的分布式存儲CynosStore負責人。從事數(shù)據(jù)庫內(nèi)核開發(fā)、數(shù)據(jù)庫產(chǎn)品架構和規(guī)劃。曾就職于華為，2015年加入騰訊，參與過TBase(PGXZ)、CynosDB等數(shù)據(jù)庫產(chǎn)品研發(fā)。專注于關系數(shù)據(jù)庫、數(shù)據(jù)庫集群、新型數(shù)據(jù)庫架構等領域。目前擔任CynosDB的分布式存儲CynosStore負責人。
企業(yè)IT系統(tǒng)遷移到公有云上已然是正在發(fā)生的趨勢。數(shù)據(jù)庫服務，作為公有云上提供的關鍵組件，是企業(yè)客戶是否愿意將自己運行多年的系統(tǒng)搬到云上的關鍵考量之一。另一方面，自從System R開始，關系數(shù)據(jù)庫系統(tǒng)已經(jīng)大約四十年的歷史了。尤其是隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)務對數(shù)據(jù)庫實例的吞吐量要求越來越高。對于很多業(yè)務來說，單個物理機器所能提供的最大吞吐量已經(jīng)不能滿足業(yè)務的高速發(fā)展。因此，數(shù)據(jù)庫集群是很多IT系統(tǒng)繞不過去的坎。
CynosDB for PostgreSQL是騰訊云自研的一款云原生數(shù)據(jù)庫，其主要核心思想來自于亞馬遜的云數(shù)據(jù)庫服務Aurora。這種核心思想就是“基于日志的存儲”和“存儲計算分離”。同時，CynosDB在架構和工程實現(xiàn)上確實有很多和Aurora不一樣的地方。CynosDB相比傳統(tǒng)的單機數(shù)據(jù)庫，主要解決如下問題：
存算分離
存算分離是云數(shù)據(jù)庫區(qū)別于傳統(tǒng)數(shù)據(jù)庫的主要特點之一，主要是為了1)提升資源利用效率，用戶用多少資源就給多少資源；2)計算節(jié)點無狀態(tài)更有利于數(shù)據(jù)庫服務的高可用性和集群管理(故障恢復、實例遷移)的便利性。
存儲自動擴縮容
傳統(tǒng)關系型數(shù)據(jù)庫會受到單個物理機器資源的限制，包括單機上存儲空間的限制和計算能力的限制。CynosDB采用分布式存儲來突破單機存儲限制。另外，存儲支持多副本，通過RAFT協(xié)議來保證多副本的一致性。
更高的網(wǎng)絡利用率
通過基于日志的存儲設計思路，大幅度降低數(shù)據(jù)庫運行過程中的網(wǎng)絡流量。
更高的吞吐量
傳統(tǒng)的數(shù)據(jù)庫集群，面臨的一個關鍵問題是：分布式事務和集群吞吐量線性擴展的矛盾。也就是說，很多數(shù)據(jù)庫集群，要么支持完整的ACID，要么追求極好的線性擴展性，大部分時候魚和熊掌不可兼得。前者比如Oracle RAC，是目前市場上最成熟最完善的數(shù)據(jù)庫集群，提供對業(yè)務完全透明的數(shù)據(jù)訪問服務。但是Oracle RAC的線性擴展性卻被市場證明還不夠，因此，更多用戶主要用RAC來構建高可用集群，而不是高擴展的集群。后者比如Proxy+開源DB的數(shù)據(jù)庫集群方案，通常能提供很好的線性擴展性，但是因為不支持分布式事務，對數(shù)據(jù)庫用戶存在較大的限制。又或者可以支持分布式事務，但是當跨節(jié)點寫入比例很大時，反過來降低了線性擴展能力。CynosDB通過采用一寫多讀的方式，利用只讀節(jié)點的線性擴展來提升整個系統(tǒng)的最大吞吐量，對于絕大部份公有云用戶來說，這就已經(jīng)足夠了。
存儲自動擴縮容
傳統(tǒng)關系型數(shù)據(jù)庫會受到單個物理機器資源的限制，包括單機上存儲空間的限制和計算能力的限制。CynosDB采用分布式存儲來突破單機存儲限制。另外，存儲支持多副本，通過RAFT協(xié)議來保證多副本的一致性。
更高的網(wǎng)絡利用率
通過基于日志的存儲設計思路，大幅度降低數(shù)據(jù)庫運行過程中的網(wǎng)絡流量。
更高的吞吐量
傳統(tǒng)的數(shù)據(jù)庫集群，面臨的一個關鍵問題是：分布式事務和集群吞吐量線性擴展的矛盾。也就是說，很多數(shù)據(jù)庫集群，要么支持完整的ACID，要么追求極好的線性擴展性，大部分時候魚和熊掌不可兼得。前者比如Oracle RAC，是目前市場上最成熟最完善的數(shù)據(jù)庫集群，提供對業(yè)務完全透明的數(shù)據(jù)訪問服務。但是Oracle RAC的線性擴展性卻被市場證明還不夠，因此，更多用戶主要用RAC來構建高可用集群，而不是高擴展的集群。后者比如Proxy+開源DB的數(shù)據(jù)庫集群方案，通常能提供很好的線性擴展性，但是因為不支持分布式事務，對數(shù)據(jù)庫用戶存在較大的限制。又或者可以支持分布式事務，但是當跨節(jié)點寫入比例很大時，反過來降低了線性擴展能力。CynosDB通過采用一寫多讀的方式，利用只讀節(jié)點的線性擴展來提升整個系統(tǒng)的最大吞吐量，對于絕大部份公有云用戶來說，這就已經(jīng)足夠了。
下圖為CynosDB for PostgreSQL的產(chǎn)品架構圖，CynosDB是一個基于共享存儲、支持一寫多讀的數(shù)據(jù)庫集群。
CynosDB for PostgreSQL產(chǎn)品架構圖
圖一CynosDB for PostgreSQL產(chǎn)品架構圖
CynosDB基于CynosStore之上，CynosStore是一個分布式存儲，為CynosDB提供堅實的底座。CynosStore由多個Store Node和CynosStore Client組成。CynosStore Client以二進制包的形式與DB(PostgreSQL)一起編譯，為DB提供訪問接口，以及負責主從DB之間的日志流傳輸。除此之外，每個Store Node會自動將數(shù)據(jù)和日志持續(xù)地備份到騰訊云對象存儲服務COS上，用來實現(xiàn)PITR(即時恢復)功能。
一、CynosStore數(shù)據(jù)組織形式
CynosStore會為每一個數(shù)據(jù)庫分配一段存儲空間，我們稱之為Pool，一個數(shù)據(jù)庫對應一個Pool。數(shù)據(jù)庫存儲空間的擴縮容是通過Pool的擴縮容來實現(xiàn)的。一個Pool會分成多個Segment Group(SG)，每個SG固定大小為10G。我們也把每個SG叫做一個邏輯分片。一個Segment Group(SG)由多個物理的Segment組成，一個Segment對應一個物理副本，多個副本通過RAFT協(xié)議來實現(xiàn)一致性。Segment是CynosStore中最小的數(shù)據(jù)遷移和備份單位。每個SG保存屬于它的數(shù)據(jù)以及對這部分數(shù)據(jù)最近一段時間的寫日志。
CynosStore 數(shù)據(jù)組織形式
圖二 CynosStore 數(shù)據(jù)組織形式
圖二中CynosStore一共有3個Store Node，CynosStore中創(chuàng)建了一個Pool，這個Pool由3個SG組成，每個SG有3個副本。CynosStore還有空閑的副本，可以用來給當前Pool擴容，也可以創(chuàng)建另一個Pool，將這空閑的3個Segment組成一個SG并分配個這個新的Pool。
二、基于日志異步寫的分布式存儲
傳統(tǒng)的數(shù)據(jù)通常采用WAL(日志先寫)來實現(xiàn)事務和故障恢復。這樣做最直觀的好處是1)數(shù)據(jù)庫down機后可以根據(jù)持久化的WAL來恢復數(shù)據(jù)頁。2)先寫日志，而不是直接寫數(shù)據(jù)，可以在數(shù)據(jù)庫寫操作的關鍵路徑上將隨機IO(寫數(shù)據(jù)頁)變成順序IO(寫日志)，便于提升數(shù)據(jù)庫性能。
基于日志的存儲
圖三 基于日志的存儲
圖三(左)極度抽象地描述了傳統(tǒng)數(shù)據(jù)庫寫數(shù)據(jù)的過程：每次修改數(shù)據(jù)的時候，必須保證日志先持久化之后才可以對數(shù)據(jù)頁進行持久化。觸發(fā)日志持久化的時機通常有
1)事務提交時，這個事務產(chǎn)生的最大日志點之前的所有日志必須持久化之后才能返回給客戶端事務提交成功；
2)當日志緩存空間不夠用時，必須持久化之后才能釋放日志緩存空間；
3)當數(shù)據(jù)頁緩存空間不夠用時，必須淘汰部分數(shù)據(jù)頁來釋放緩存空間。比如根據(jù)淘汰算法必須要淘汰臟頁A，那么最后修改A的日志點之前的所有日志必須先持久化，然后才可以持久化A到存儲，最后才能真正從數(shù)據(jù)緩存空間中將A淘汰。
從理論上來說，數(shù)據(jù)庫只需要持久化日志就可以了。因為只要擁有從數(shù)據(jù)庫初始化時刻到當前的所有日志，數(shù)據(jù)庫就能恢復出當前任何一個數(shù)據(jù)頁的內(nèi)容。也就是說，數(shù)據(jù)庫只需要寫日志，而不需要寫數(shù)據(jù)頁，就能保證數(shù)據(jù)的完整性和正確性。但是，實際上數(shù)據(jù)庫實現(xiàn)者不會這么做，因為1)從頭到尾遍歷日志恢復出每個數(shù)據(jù)頁將是非常耗時的；2)全量日志比數(shù)據(jù)本身規(guī)模要大得多，需要更多的磁盤空間去存儲。
那么，如果持久化日志的存儲設備不僅僅具有存儲能力，還擁有計算能力，能夠自行將日志重放到最新的頁的話，將會怎么樣？是的，如果這樣的話，數(shù)據(jù)庫引擎就沒有必要將數(shù)據(jù)頁傳遞給存儲了，因為存儲可以自行計算出新頁并持久化。這就是CynosDB“采用基于日志的存儲”的核心思想。圖三(右)極度抽象地描述了這種思想。圖中計算節(jié)點和存儲節(jié)點置于不同的物理機，存儲節(jié)點除了持久化日志以外，還具備通過apply日志生成最新數(shù)據(jù)頁面的能力。如此一來，計算節(jié)點只需要寫日志到存儲節(jié)點即可，而不需要再將數(shù)據(jù)頁傳遞給存儲節(jié)點。
下圖描述了采用基于日志存儲的CynosStore的結(jié)構。
基于日志的存儲
圖四 CynosStore：基于日志的存儲
此圖描述了數(shù)據(jù)庫引擎如何訪問CynosStore。數(shù)據(jù)庫引擎通過CynosStore Client來訪問CynosStore。最核心的兩個操作包括1)寫日志；2)讀數(shù)據(jù)頁。
數(shù)據(jù)庫引擎將數(shù)據(jù)庫日志傳遞給CynosStore，CynosStore Client負責將數(shù)據(jù)庫日志轉(zhuǎn)換成CynosStore Journal，并且負責將這些并發(fā)寫入的Journal進行序列化，最后根據(jù)Journal修改的數(shù)據(jù)頁路由到不同的SG上去，并發(fā)送給SG所屬Store Node。另外，CynosStore Client采用異步的方式監(jiān)聽各個Store Node的日志持久化確認消息，并將歸并之后的最新的持久化日志點告訴數(shù)據(jù)庫引擎。
當數(shù)據(jù)庫引擎訪問的數(shù)據(jù)頁在緩存中不命中時，需要向CynosStore讀取需要的頁(read block)。read block是同步操作。并且，CynosStore支持一定時間范圍的多版本頁讀取。因為各個Store Node在重放日志時的步調(diào)不能完全做到一致，總會有先有后，因此需要讀請求發(fā)起者提供一致性點來保證數(shù)據(jù)庫引擎所要求的一致性，或者默認情況下由CynosStore用最新的一致性點(讀點)去讀數(shù)據(jù)頁。另外，在一寫多讀的場景下，只讀數(shù)據(jù)庫實例也需要用到CynosStore提供的多版本特性。
CynosStore提供兩個層面的訪問接口：一個是塊設備層面的接口，另一個是基于塊設備的文件系統(tǒng)層面的接口。分別叫做CynosBS和CynosFS，他們都采用這種異步寫日志、同步讀數(shù)據(jù)的接口形式。那么，CynosDB for PostgreSQL，采用基于日志的存儲，相比一主多從PostgreSQL集群來說，到底能帶來哪些好處？
1)減少網(wǎng)絡流量。首先，只要存算分離就避免不了計算節(jié)點向存儲節(jié)點發(fā)送數(shù)據(jù)。如果我們還是使用傳統(tǒng)數(shù)據(jù)庫+網(wǎng)絡硬盤的方式來做存算分離(計算和存儲介質(zhì)的分離)，那么網(wǎng)絡中除了需要傳遞日志以外，還需要傳遞數(shù)據(jù)，傳遞數(shù)據(jù)的大小由并發(fā)寫入量、數(shù)據(jù)庫緩存大小、以及checkpoint頻率來決定。以CynosStore作為底座的CynosDB只需要將日志傳遞給CynosStore就可以了，降低網(wǎng)絡流量。
2)更加有利于基于共享存儲的集群的實現(xiàn)：一個數(shù)據(jù)庫的多個實例(一寫多讀)訪問同一個Pool。基于日志寫的CynosStore能夠保證只要DB主節(jié)點(讀寫節(jié)點)寫入日志到CynosStore，就能讓從節(jié)點(只讀節(jié)點)能夠讀到被這部分日志修改過的數(shù)據(jù)頁最新版本，而不需要等待主節(jié)點通過checkpoint等操作將數(shù)據(jù)頁持久化到存儲才能讓讀節(jié)點見到最新數(shù)據(jù)頁。這樣能夠大大降低主從數(shù)據(jù)庫實例之間的延時。不然，從節(jié)點需要等待主節(jié)點將數(shù)據(jù)頁持久化之后(checkpoint)才能推進讀點。如果這樣，對于主節(jié)點來說，checkpoint的間隔太久的話，就會導致主從延時加大，如果checkpoint間隔太小，又會導致主節(jié)點寫數(shù)據(jù)的網(wǎng)絡流量增大。
當然，apply日志之后的新數(shù)據(jù)頁的持久化，這部分工作總是要做的，不會憑空消失，只是從數(shù)據(jù)庫引擎下移到了CynosStore。但是正如前文所述，除了降低不必要的網(wǎng)絡流量以外，CynosStore的各個SG是并行來做redo和持久化的。并且一個Pool的SG數(shù)量可以按需擴展，SG的宿主Store Node可以動態(tài)調(diào)度，因此可以用非常靈活和高效的方式來完成這部分工作。
三、CynosStore Journal(CSJ)
CynosStore Journal(CSJ)完成類似數(shù)據(jù)庫日志的功能，比如PostgreSQL的WAL。CSJ與PostgreSQL WAL不同的地方在于：CSJ擁有自己的日志格式，與數(shù)據(jù)庫語義解耦合。PostgreSQL WAL只有PostgreSQL引擎可以生成和解析，也就是說，當其他存儲引擎拿到PostgreSQL WAL片段和這部分片段所修改的基礎頁內(nèi)容，也沒有辦法恢復出最新的頁內(nèi)容。CSJ致力于定義一種與各種存儲引擎邏輯無關的日志格式，便于建立一個通用的基于日志的分布式存儲系統(tǒng)。CSJ定了5種Journal類型：
1.SetByte：用Journal中的內(nèi)容覆蓋指定數(shù)據(jù)頁中、指定偏移位置、指定長度的連續(xù)存儲空間。
\2. SetBit：與SetByte類似，不同的是SetBit的最小粒度是Bit，例如PostgreSQL中hitbit信息，可以轉(zhuǎn)換成SetBit日志。
\3. ClearPage：當新分配Page時，需要將其初始化，此時新分配頁的原始內(nèi)容并不重要，因此不需要將其從物理設備中讀出來，而僅僅需要用一個全零頁寫入即可，ClearPage就是描述這種修改的日志類型。
\4. DataMove：有一些寫入操作將頁面中一部分的內(nèi)容移動到另一個地方，DataMove類型的日志用來描述這種操作。比如PostgreSQL在Vacuum過程中對Page進行compact操作，此時用DataMove比用SetByte日志量更小。
\5. UserDefined：數(shù)據(jù)庫引擎總會有一些操作并不會修改某個具體的頁面內(nèi)容，但是需要存放在日志中。比如PostgreSQL的最新的事務id(xid)就是存儲在WAL中，便于數(shù)據(jù)庫故障恢復時知道從那個xid開始分配。這種類型日志跟數(shù)據(jù)庫引擎語義相關，不需要CynosStore去理解，但是又需要日志將其持久化。UserDefined就是來描述這種日志的。CynosStore針對這種日志只負責持久化和提供查詢接口，apply CSJ時會忽略它。
以上5種類型的Journal是存儲最底層的日志，只要對數(shù)據(jù)的寫是基于塊/頁的，都可以轉(zhuǎn)換成這5種日志來描述。當然，也有一些引擎不太適合轉(zhuǎn)換成這種最底層的日志格式，比如基于LSM的存儲引擎。
CSJ的另一個特點是亂序持久化，因為一個Pool的CSJ會路由到多個SG上，并且采用異步寫入的方式。而每個SG返回的journal ack并不同步，并且相互穿插，因此CynosStore Client還需要將這些ack進行歸并并推進連續(xù)CSJ點(VDL)。
CynosStore日志路由和亂序ACK
圖五 CynosStore日志路由和亂序ACK
只要是連續(xù)日志根據(jù)數(shù)據(jù)分片路由，就會有日志亂序ack的問題，從而必須對日志ack進行歸并。Aurora有這個機制，CynosDB同樣有。為了便于理解，我們對Journal中的各個關鍵點的命名采用跟Aurora同樣的方式。
這里需要重點描述的是MTR，MTR是CynosStore提供的原子寫單位，CSJ就是由一個MTR緊挨著一個MTR組成的，任意一個日志必須屬于一個MTR，一個MTR中的多條日志很有可能屬于不同的SG。針對PostgreSQL引擎，可以近似理解為：一個XLogRecord對應一個MTR，一個數(shù)據(jù)庫事務的日志由一個或者多個MTR組成，多個數(shù)據(jù)庫并發(fā)事務的MTR可以相互穿插。但是CynosStore并不理解和感知數(shù)據(jù)庫引擎的事務邏輯，而只理解MTR。發(fā)送給CynosStore的讀請求所提供的讀點必須不能在一個MTR的內(nèi)部某個日志點。簡而言之，MTR就是CynosStore的事務。
四、故障恢復
當主實例發(fā)生故障后，有可能這個主實例上Pool中各個SG持久化的日志點在全局范圍內(nèi)并不連續(xù)，或者說有空洞。而這些空洞所對應的日志內(nèi)容已經(jīng)無從得知。比如有3條連續(xù)的日志j1, j2, j3分別路由到三個SG上，分別為sg1, sg2, sg3。在發(fā)生故障的那一刻，j1和j3已經(jīng)成功發(fā)送到sg1和sg3。但是j2還在CynosStore Client所在機器的網(wǎng)絡緩沖區(qū)中，并且隨著主實例故障而丟失。那么當新的主實例啟動后，這個Pool上就會有不連續(xù)的日志j1, j3，而j2已經(jīng)丟失。
當這種故障場景發(fā)生后，新啟動的主實例將會根據(jù)上次持久化的連續(xù)日志VDL，在每個SG上查詢自從這個VDL之后的所有日志，并將這些日志進行歸并，計算出新的連續(xù)持久化的日志號VDL。這就是新的一致性點。新實例通過CynosStore提供的Truncate接口將每個SG上大于VDL的日志truncate掉，那么新實例產(chǎn)生的第一條journal將從這個新的VDL的下一條開始。
故障恢復時日志恢復過程
圖六：故障恢復時日志恢復過程
如果圖五剛好是某個數(shù)據(jù)庫實例故障發(fā)生的時間點，當重新啟動一個數(shù)據(jù)庫讀寫實例之后，圖六就是計算新的一致性點的過程。CynosStore Client會計算得出新的一致性點就是8，并且把大于8的日志都Truncate掉。也就是把SG2上的9和10truncate掉。下一個產(chǎn)生的日志將會從9開始。
五、多副本一致性
CynosStore采用Multi-RAFT來實現(xiàn)SG的多副本一致性， CynosStore采用批量和異步流水線的方式來提升RAFT的吞吐量。我們采用CynosStore自定義的benchmark測得單個SG上日志持久化的吞吐量為375萬條/每秒。CynosStore benchmark采用異步寫入日志的方式測試CynosStore的吞吐量，日志類型包含SetByte和SetBit兩種，寫日志線程持續(xù)不斷地寫入日志，監(jiān)聽線程負責處理ack回包并推進VDL，然后benchmark測量單位時間內(nèi)VDL的推進速度。375萬條/秒意味著每秒鐘一個SG持久化375萬條SetByte和SetBit日志。在一個SG的場景下，CynosStore Client到Store Node的平均網(wǎng)絡流量171MB/每秒，這也是一個Leader到一個Follower的網(wǎng)絡流量。
六、一寫多讀
CynosDB基于共享存儲CynosStore，提供對同一個Pool上的一寫多讀數(shù)據(jù)庫實例的支持，以提升數(shù)據(jù)庫的吞吐量?；诠蚕泶鎯Φ囊粚懚嘧x需要解決兩個問題：
\1. 主節(jié)點(讀寫節(jié)點)如何將對頁的修改通知給從節(jié)點(只讀節(jié)點)。因為從節(jié)點也是有Buffer的，當從節(jié)點緩存的頁面在主節(jié)點中被修改時，從節(jié)點需要一種機制來得知這個被修改的消息，從而在從節(jié)點Buffer中更新這個修改或者從CynosStore中重讀這個頁的新版本。
\2. 從節(jié)點上的讀請求如何讀到數(shù)據(jù)庫的一致性的快照。開源PostgreSQL的主備模式中，備機通過利用主機同步過來的快照信息和事務信息構造一個快照(活動事務列表)。CynosDB的從節(jié)點除了需要數(shù)據(jù)庫快照(活動事務列表)以外，還需要一個CynosStore的快照(一致性讀點)。因為分片的日志時并行apply的。
如果一個一寫多讀的共享存儲數(shù)據(jù)庫集群的存儲本身不具備日志重做的能力，主從內(nèi)存頁的同步有兩種備選方案：
第一種備選方案，主從之間只同步日志。從實例將至少需要保留主實例自從上次checkpoint以來所有產(chǎn)生的日志，一旦從實例產(chǎn)生cache miss，只能從存儲上讀取上次checkpoint的base頁，并在此基礎上重放日志緩存中自上次checkpoint以來的所有關于這個頁的修改。這種方法的關鍵問題在于如果主實例checkpoint之間的時間間隔太長，或者日志量太大，會導致從實例在命中率不高的情況下在apply日志上耗費非常多的時間。甚至，極端場景下，導致從實例對同一個頁會反復多次apply同一段日志，除了大幅增大查詢時延，還產(chǎn)生了很多沒必要的CPU開銷，同時也會導致主從之間的延時有可能大幅增加。
第二種備選方案，主實例向從實例提供讀取內(nèi)存緩沖區(qū)數(shù)據(jù)頁的服務，主實例定期將被修改的頁號和日志同步給從實例。當讀頁時，從實例首先根據(jù)主實例同步的被修改的頁號信息來判斷是1)直接使用從實例自己的內(nèi)存頁，還是2)根據(jù)內(nèi)存頁和日志重放新的內(nèi)存頁，還是3)從主實例拉取最新的內(nèi)存頁，還是4)從存儲讀取頁。這種方法有點類似Oracle RAC的簡化版。這種方案要解決兩個關鍵問題：1)不同的從實例從主實例獲取的頁可能是不同版本，主實例內(nèi)存頁服務有可能需要提供多版本的能力。2)讀內(nèi)存頁服務可能對主實例產(chǎn)生較大負擔，因為除了多個從實例的影響以外，還有一點就是每次主實例中的某個頁哪怕修改很小的一部分內(nèi)容，從實例如果讀到此頁則必須拉取整頁內(nèi)容。大致來說，主實例修改越頻繁，從實例拉取也會更頻繁。
相比較來說，CynosStore也需要同步臟頁，但是CynosStore的從實例獲取新頁的方式要靈活的多有兩種選擇1)從日志重放內(nèi)存頁；2)從StoreNode讀取。從實例對同步臟頁需要的最小信息僅僅是到底哪些頁被主實例給修改過，主從同步日志內(nèi)容是為了讓從實例加速，以及降低Store Node的負擔。
CynosDB一寫多讀
圖七 CynosDB一寫多讀
圖七描述了一寫一讀(一主一從)的基本框架，一寫多讀(一主多從)就是一寫一讀的疊加。CynosStore Client(CSClient)運行態(tài)區(qū)分主從，主CSClient源源不斷地將CynosStore Journal(CSJ)從主實例發(fā)送到從實例，與開源PostgreSQL主備模式不同的是，只要這些連續(xù)的日志到達從實例，不用等到這些日志全部apply，DB engine就可以讀到這些日志所修改的最新版本。從而降低主從之間的時延。這里體現(xiàn)“基于日志的存儲”的優(yōu)勢：只要主實例將日志持久化到Store Node，從實例即可讀到這些日志所修改的最新版本數(shù)據(jù)頁。
七、結(jié)語
CynosStore是一個完全從零打造、適應云數(shù)據(jù)庫的分布式存儲。CynosStore在架構上具備一些天然優(yōu)勢：1)存儲計算分離，并且把存儲計算的網(wǎng)絡流量降到最低； 2)提升資源利用率，降低云成本，3)更加有利于數(shù)據(jù)庫實例實現(xiàn)一寫多讀，4)相比一主兩從的傳統(tǒng)RDS集群具備更高的性能。除此之外，后續(xù)我們會在性能、高可用、資源隔離等方面對CynosStore進行進一步的增強。
此文已由作者授權騰訊云+社區(qū)發(fā)布
總結(jié)
以上是生活随笔為你收集整理的腾讯云mysql架构_一个数据库存储架构的独白的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [转载] Java ArrayList
- 下一篇： 基本linux命令vi,基本linux和