隨著接觸的分布式系統(tǒng)（產(chǎn)品）越來越多，關(guān)于分布式系統(tǒng)的數(shù)據(jù)存儲逐漸有了一些理解，進(jìn)行統(tǒng)一整理和梳理。

1. 數(shù)據(jù)存儲場景和存儲策略

在進(jìn)行分布式系統(tǒng)設(shè)計時，面臨的數(shù)據(jù)場景不同，因此對應(yīng)的產(chǎn)品在進(jìn)行架構(gòu)設(shè)計時也采用了不同的存儲策略。但是總的說來，主要包括如下兩類。

1.1 鏡像模式-小規(guī)模數(shù)據(jù)

小規(guī)模數(shù)據(jù)場景主要包括： 元數(shù)據(jù)、少量業(yè)務(wù)數(shù)據(jù)等。這種數(shù)據(jù)類型的特點是，存儲的數(shù)據(jù)量一般都比較?。ū热?0G以內(nèi)）。通常情況下，單個節(jié)點能夠滿足數(shù)據(jù)的存儲、讀寫性能要求，因此該類型的分布式產(chǎn)品在設(shè)計時通常使用鏡像模式進(jìn)行存儲。單節(jié)點保存所有數(shù)據(jù)（業(yè)務(wù)數(shù)據(jù)+元數(shù)據(jù)），通過多節(jié)點（主從模式，強(qiáng)同步或者半強(qiáng)同步）形成多副本，從而保證數(shù)據(jù)的一致性。主從模式能夠避免數(shù)據(jù)不一致的問題，不同節(jié)點通過復(fù)雜的選主邏輯選擇最合適的節(jié)點作為leader，leader節(jié)點響應(yīng)客戶端的寫請求，從節(jié)點響應(yīng)客戶端的讀請求（不同產(chǎn)品有差異）。該類型常見的產(chǎn)品如zk、etcd等。

參考zk的架構(gòu)圖如下

1.2 分片模式-大規(guī)模數(shù)據(jù)

大規(guī)模數(shù)據(jù)場景主要包括：大數(shù)據(jù)、日志、圖片、大量文檔數(shù)據(jù)等，這種數(shù)據(jù)類型的特點是，存儲的數(shù)據(jù)規(guī)模大（TB級別甚至更高）。通常情況下，單節(jié)點無法滿足數(shù)據(jù)存儲需求（單節(jié)點的磁盤、cpu內(nèi)存等成為瓶頸），因此該類型的分布式產(chǎn)品在設(shè)計時通常使用分片模式進(jìn)行存儲。 將一個完整的業(yè)務(wù)數(shù)據(jù)（比如大索引）拆分成多個分片進(jìn)行存儲，不同分片分散在不同的節(jié)點上，從而規(guī)避單節(jié)點性能不足問題。這種類型的架構(gòu)模式需要master角色，保存整個集群的元數(shù)據(jù)，從而形成上帝視角，用于進(jìn)行數(shù)據(jù)分配、調(diào)度等職責(zé)。常見的產(chǎn)品如hdfs、hbase、es等

參考es的架構(gòu)圖如下

2. 數(shù)據(jù)一致性和高可用問題

數(shù)據(jù)一致性和高可用是分布式場景下，面臨的2個最核心問題。后續(xù)將重點開展鏡像模式是如何實現(xiàn)數(shù)據(jù)一致性和高可用的。分片模式通常是在鏡像模式下進(jìn)行相應(yīng)的組合而成。

2.1 鏡像模式如何保證數(shù)據(jù)一致性

鏡像模式下，由于單節(jié)點已經(jīng)保存了所有的數(shù)據(jù)（元數(shù)據(jù)+業(yè)務(wù)數(shù)據(jù)），因此在架構(gòu)上只需要進(jìn)行選主+多副本，就可以解決避免數(shù)據(jù)一致性和高可用問題。

數(shù)據(jù)一致性：通過選主選擇出集群的leader節(jié)點，響應(yīng)客戶端的寫需求，并且通過數(shù)據(jù)強(qiáng)同步（或者半強(qiáng)同步）將數(shù)據(jù)同步到其他的節(jié)點，從而保證數(shù)據(jù)一致性。

當(dāng)客戶端進(jìn)行數(shù)據(jù)寫入時，形成一個寫入的事務(wù)，會面臨多種情況。

1，集群的leader節(jié)點+所有（或者多個）節(jié)點完成數(shù)據(jù)寫入，才能認(rèn)為數(shù)據(jù)已經(jīng)完成寫入，并返回給客戶端，此時客戶端才能認(rèn)為數(shù)據(jù)已經(jīng)寫入到集群中，客戶端進(jìn)行事務(wù)提交，一個完整的數(shù)據(jù)事務(wù)完成。此時集群需要承諾客戶端，寫入的數(shù)據(jù)不丟失。

2，如果客戶端在發(fā)起寫入事務(wù)后，集群內(nèi)部不同節(jié)點出現(xiàn)了異常（比如一個非leader節(jié)點突然宕機(jī)），面對這種情況不同的產(chǎn)品的響應(yīng)策略不同（一些產(chǎn)品直接返回失敗，一些產(chǎn)品會跳過異常的節(jié)點繼續(xù)寫入其他節(jié)點盡可能保證寫入成功）。但是整體上的一個策略是，如果不滿足集群的leader節(jié)點+所有（或者多個）節(jié)點完成數(shù)據(jù)寫入，會將返回結(jié)果返回客戶客戶端，由客戶端決定這條數(shù)據(jù)的去留（重試或者丟棄）。這種模式下，數(shù)據(jù)的一致性需要客戶端進(jìn)行參與，如果客戶端忽略了集群的異常返回（或者返回碼），就會可能導(dǎo)致數(shù)據(jù)丟失。

相關(guān)的寫入流程可以參考etcd的寫入流程

3，不同的產(chǎn)品在設(shè)計上不同

有些產(chǎn)品把**集群的leader節(jié)點+所有（或者多個）**的決定權(quán)保留給客戶端，客戶端在寫入的時候選擇對應(yīng)的模式，通常有如下幾種模式

• 直接返回
• 數(shù)據(jù)寫入leader就返回
• leader+所有節(jié)點寫入成功就返回
• leader+多個節(jié)點寫入成功就返回

比如kafka在客戶端寫入數(shù)據(jù)是需要客戶端指定acks策略。

有些產(chǎn)品則不允許客戶端做出相關(guān)的選擇，只有一種集群的內(nèi)部定義的模式。

因此不同的客戶端需要根據(jù)不同的產(chǎn)品特性進(jìn)行相關(guān)的適配。

2.2 鏡像模式如何保證數(shù)據(jù)高可用

鏡像模式下，通過leader+多節(jié)點的方式實現(xiàn)數(shù)據(jù)多副本，從而實現(xiàn)數(shù)據(jù)高可用，不同產(chǎn)品的選主有差異，通常的選主方式有2種

• HA模式
• 分布式選主模式

2.2.1 HA模式

HA模式的實現(xiàn)方式有很多種，最常見的方式是，通過分布式鎖實現(xiàn)，比如在zk中注冊一個臨時節(jié)點。

1，成功在zk中創(chuàng)建了臨時目錄的節(jié)點獲取對應(yīng)的分布式鎖權(quán)限，從而成為leader，并且需要定期到zk中發(fā)送心跳，給臨時目錄續(xù)期。臨時目錄有一個特點，如果在ttl時間內(nèi)沒有被續(xù)期，就會自動消失。

2， 其余節(jié)點通過watch的方式監(jiān)聽這個臨時目錄，如果原leader在ttl時間內(nèi)沒有同步心跳，臨時目錄就會自動消失，zk給所有的watch客戶端發(fā)送相關(guān)的事件

3， 收到zk的事件，集群的節(jié)點都搶鎖（在zk中創(chuàng)建臨時目錄），搶到鎖的節(jié)點升級為新leader

4，新leader發(fā)送廣播告知所有的節(jié)點，新leader已經(jīng)產(chǎn)生。

5，通常新leader產(chǎn)生后，老leader可能還存活，需要一定的策略將老leader降級，從能避免腦裂，比如hdfs的nn通過fencing策略將老leader降級（先rpc降級，如果rpc降級失敗，則ssh到對應(yīng)的機(jī)器上殺死進(jìn)程）。

2.2.2 分布式選主模式

常見的選擇主協(xié)議有Paxos，Raft，ZAB等多種協(xié)議進(jìn)行選主邏輯，獲取超過半數(shù)(n+1/2)投票的節(jié)點成為leader。由于不同節(jié)點之間的數(shù)據(jù)可能有差異，因此選舉出leader后，需要根據(jù)情況進(jìn)行合并數(shù)據(jù)（將不同節(jié)點的事務(wù)進(jìn)行合并，形成完整的數(shù)據(jù)）。

不同協(xié)議的選主邏輯差異，可以參考 Paxos，Raft，ZAB的差異對比

通常情況下，通過一致性選主協(xié)議進(jìn)行數(shù)據(jù)選主的集群，需要獲取超過半數(shù)節(jié)點投票才能成為leader，因此通常部署單數(shù)節(jié)點，能夠容忍集群內(nèi)部網(wǎng)絡(luò)隔離異常。并且集群能夠容忍的異常節(jié)點數(shù)量是(n-1)/2，相對于雙數(shù)節(jié)點部署，單數(shù)節(jié)點部署能夠更節(jié)省資源，也更加合理。

raft的選主邏輯大致如下，其他協(xié)議的選主邏輯也跟raft大致差不多。

1，初始狀態(tài)

Raft 每個節(jié)點初始化后的心跳超時時間都是隨機(jī)的，如上所示，節(jié)點 C 的超時時間最短（120ms），任期編號都為 0，角色都是跟隨者。

2，請求投票

此時沒有一個節(jié)點是leader，節(jié)點等待心跳超時后，會推薦自己為候選人，向集群其他節(jié)點發(fā)起請求投票信息，此時任期編號 +1，自薦會獲得自己的一票選票。

3，跟隨者投票

跟隨者收到請求投票信息后，如果該候選人符合投票要求后，則將自己寶貴（因為每個任期內(nèi)跟隨者只能投給先來的候選人一票，后面來的候選人則不能在投票給它了）的一票投給該候選人，同時更新任期編號。

4，當(dāng)選leader

當(dāng)節(jié)點 C 贏得大多數(shù)選票后，它會成為本次任期的leader。

5，leader與跟隨者保持心跳

leader周期性發(fā)送心跳消息給其他節(jié)點，告知自己是leader，同時刷新跟隨者的超時時間，防止跟隨者發(fā)起新的leader選舉。

2.3 分片模式如何數(shù)據(jù)一致性和高可用

分片模式在一定程度上是將大數(shù)據(jù)按照分片進(jìn)行拆分，形成多個小分片，在每個小分片的整體數(shù)據(jù)一致性和高可用邏輯（主從多副本）跟鏡像模式是一致的。

比如hdfs的架構(gòu)如下

將hdfs進(jìn)行拆分，主要分為2塊

1，NN節(jié)點（2個nn），保存集群的元數(shù)據(jù)，構(gòu)建集群的數(shù)據(jù)全局視角，使用HA模式進(jìn)行實現(xiàn)高可用。

2，DN節(jié)點，將文件以block作為基礎(chǔ)存儲單元分散在不同的DN節(jié)點，單個block通常有3個副本，3個副本分散在不同機(jī)器/機(jī)架上，并進(jìn)行內(nèi)部選主。

如上2個模塊， 均是將大系統(tǒng)拆分成小模塊，利用鏡像模式的基礎(chǔ)方法實現(xiàn)數(shù)據(jù)一致性和高可用。

3. 大規(guī)模數(shù)據(jù)集群的架構(gòu)設(shè)計模式

通常針對大規(guī)模集群，在系統(tǒng)架構(gòu)的設(shè)計上主要是分2類

• 中心化模式
• 去中心化模式

量者有比較大的區(qū)別，并且優(yōu)缺點也比較明顯

3.1 中心化模式

所謂中心化模式，就是在集群內(nèi)部選擇一些節(jié)點（角色）存儲集群的元數(shù)據(jù)，從而構(gòu)建集群的數(shù)據(jù)全局視角，不同產(chǎn)品的實現(xiàn)方式有差異。

例如

• hdfs的nn節(jié)點，通過dn定期匯報狀態(tài)和數(shù)據(jù)給nn，從而構(gòu)建和修正集群的數(shù)據(jù)，通過nn能夠獲取hdfs集群的集群數(shù)據(jù)狀態(tài)。
• kafka通過controller存儲和集群的topic和partition信息
• es通過master節(jié)點存儲集群的元數(shù)據(jù)

中心化模式
優(yōu)點：集群變更客戶端不感知，統(tǒng)一由master節(jié)點管控
缺點：master節(jié)點存儲所有的元數(shù)據(jù)（通常通過HA模式選主），master需要響應(yīng)大量的http、rpc請求進(jìn)行數(shù)據(jù)讀寫請求，因此master節(jié)點容易成為性能瓶頸。

3.2 去中心化模式

去中心化模式，是指集群中沒有節(jié)點（角色）負(fù)責(zé)構(gòu)建集群的全局視角，約定一些固定的數(shù)據(jù)存儲算法?？蛻舳巳绻枰M(jìn)行數(shù)據(jù)讀寫，需要根據(jù)約定的數(shù)據(jù)存儲算法（比如哈希）計算對應(yīng)的數(shù)據(jù)以及存儲數(shù)據(jù)所對應(yīng)的節(jié)點?？蛻舳嗽诟鷮?yīng)的節(jié)點進(jìn)行通信，進(jìn)行讀寫數(shù)據(jù)。

典型的產(chǎn)品是，redis-cluster。

去中心化的模式
優(yōu)點：客戶端自己完成數(shù)據(jù)查找邏輯，因而節(jié)省了數(shù)據(jù)查找環(huán)節(jié)，能夠解決中心化模式的master節(jié)點性能壓力
缺點：對于集群的擴(kuò)、容規(guī)則有一定的限制，如果不合理的擴(kuò)、縮容姿勢、以及算法的變更，可能會導(dǎo)致客戶端無法通過約定的算法找到準(zhǔn)確對應(yīng)的數(shù)據(jù)存儲的節(jié)點。

4. 大規(guī)模數(shù)據(jù)集群故障轉(zhuǎn)移模式

在日常生產(chǎn)環(huán)境中，節(jié)點宕機(jī)/磁盤異常，是很常見的現(xiàn)象，因此分布式系統(tǒng)應(yīng)當(dāng)能夠容忍常規(guī)的異常，不影響集群使用。不同產(chǎn)品在設(shè)計上有差異，通常有如下2種模式

• 自動隔離，自動修復(fù)：系統(tǒng)內(nèi)部自動檢測，如果出現(xiàn)了節(jié)點宕機(jī)/磁盤異常，將讀寫從異常節(jié)點中摘除，并自動進(jìn)行數(shù)據(jù)轉(zhuǎn)移和修復(fù)，通常不需要人工參與
• 自動隔離，人工修復(fù)：系統(tǒng)內(nèi)部自動檢測，系統(tǒng)內(nèi)部自動檢測，如果出現(xiàn)了節(jié)點宕機(jī)/磁盤異常，將讀寫從異常節(jié)點中摘除。需要人工介入進(jìn)行修復(fù)。

自動隔離，應(yīng)該都很容易理解，就是將讀寫從異常節(jié)點中摘除，避免客戶端異常。差別主要在自動修復(fù)和人工修復(fù)上，兩者各有優(yōu)劣勢。

4.1 自動修復(fù)

咋一看，好像如果集群能夠自修復(fù)當(dāng)然是最好的，這樣不用人工介入，只需要等自動修復(fù)完成就好。但是實際情況來看，效果可能并不好。

最主要的限制是來自2個： 生產(chǎn)環(huán)境復(fù)雜，自動修復(fù)的時機(jī)和自動修復(fù)的進(jìn)度，難以掌握。

比如 hdfs集群，由于1個節(jié)點異常了，會觸發(fā)自動修復(fù)邏輯。自動修復(fù)主要是拷貝異常的數(shù)據(jù)到新節(jié)點，在新的節(jié)點生成合適的數(shù)據(jù)副本，但是

1， 數(shù)據(jù)拷貝需要占用一定的磁盤讀寫和網(wǎng)絡(luò)讀寫帶寬，hdfs的數(shù)據(jù)量巨大，如果不能得到合理控制可能會把機(jī)器的磁盤io和帶寬打滿，從而影響線上業(yè)務(wù)。
2， 再比如，機(jī)器可能1h就完成修復(fù)，并且上線了，步驟1中完成的讀寫修復(fù)，似乎可能多余了。 并且由于節(jié)點重新上線，又會重新觸發(fā)數(shù)據(jù)balance，又會導(dǎo)致集群的磁盤讀寫和網(wǎng)絡(luò)讀寫的帶寬，恢復(fù)過程也可能比較久。

看起來機(jī)器宕機(jī)1h在生產(chǎn)中并不是難以容忍的異常，并且也幾乎很少有概率會導(dǎo)致數(shù)據(jù)丟失，但是卻觸發(fā)了2次的數(shù)據(jù)同步，占用了磁盤讀寫和網(wǎng)絡(luò)帶寬，并可能會影響生產(chǎn)任務(wù)。雖然最終能夠完成修復(fù)，但是額外帶來了風(fēng)險，效率并不高。

4.2 人工修復(fù)

人工修復(fù)，就是需要人工介入。 比如如上的hdfs集群異常，如果不進(jìn)行自動修復(fù)，1h后機(jī)器修復(fù)正常開機(jī)并加入到集群，并不需要復(fù)雜的數(shù)據(jù)遷移和復(fù)制，由于磁盤數(shù)據(jù)都在只需要做簡單的數(shù)據(jù)校驗，就能夠恢復(fù)正常，集群恢復(fù)的效率和速度要高很多。

但是代價就是，需要實時監(jiān)控和人工介入，運維工作的量比較大，并且在一定時間內(nèi)需要承擔(dān)數(shù)據(jù)丟失的風(fēng)險，畢竟副本少了一個。

不同產(chǎn)品的設(shè)計出發(fā)點不同，有些傾向于自動修復(fù)，有些傾向于人工修復(fù)，各有利弊。我個人傾向于做一個這種，設(shè)置自動修復(fù)的窗口期（比如12h），如果不能再窗口期內(nèi)人工修復(fù)，就觸發(fā)自動修復(fù)，取得數(shù)據(jù)風(fēng)險和運維重量折中。

5. 故障轉(zhuǎn)移也是有限度的

經(jīng)常聽到有人說，集群不是分布式嗎，怎么單機(jī)故障了，集群就異常了？其實綜合各種生產(chǎn)實踐來看。常規(guī)情況下，如果單機(jī)設(shè)備異常的的比較干脆（機(jī)器宕機(jī)、磁盤不可讀寫）大多數(shù)的分布式產(chǎn)品是能夠容忍的，并且效果還是有保證的。

但是分布式系統(tǒng)的故障容忍和轉(zhuǎn)移，也是有限度的，并不是無限的單機(jī)故障（異常）都能容忍。主要的原因是來自，通常分布式產(chǎn)品內(nèi)部的節(jié)點異常，是用過探活心跳來實現(xiàn)，如果探活能夠成功，但是對應(yīng)的節(jié)點性能很糟糕，難以滿足讀寫的要求，就會導(dǎo)致由于一個慢節(jié)點，把集群完全拖垮的情況。成為單機(jī)故障的噩夢。

通常遇到的單機(jī)故障，容易導(dǎo)致集群被拖垮的現(xiàn)象不多，但是常見的有

• 機(jī)器hang住或者負(fù)載很高，能夠ping通，tcp都正常，但是機(jī)器執(zhí)行不了任何命令
• 機(jī)器的磁盤io性能很差，數(shù)據(jù)讀寫都很慢

如上2種都是日常生產(chǎn)常見的現(xiàn)象，很少有分布式組件能夠逃過這兩種因素，能夠自動完成容災(zāi)剔除，成為單機(jī)故障的噩夢

6. 系統(tǒng)穩(wěn)定性的一些建議

為了盡可能的保證生產(chǎn)穩(wěn)定性，應(yīng)當(dāng)在系統(tǒng)架構(gòu)設(shè)計上做一些更好的可靠性建設(shè)，基于日常經(jīng)驗進(jìn)行整理

6.1 梳理系統(tǒng)核心鏈路

一個分布式系統(tǒng)重，不同組件的重要度是不同的，核心鏈路涉及相關(guān)的組件和架構(gòu)，是需要定期梳理和改進(jìn)的。一個系統(tǒng)里面，幾個不同的產(chǎn)品單獨拆開用，沒問題，但是合并在一起卻可能出現(xiàn)不兼容的現(xiàn)象，因此在架構(gòu)上需要進(jìn)行梳理。

核心組件和鏈路，需要

• 區(qū)分核心鏈路和非核心鏈路
  精力重點投入在核心鏈路上，特別是架構(gòu)中的骨干環(huán)節(jié)。非核心鏈路可能會出現(xiàn)問題，但是不是大故障，通常還是能夠容忍的。

• 合理的容量設(shè)計和壓測
  系統(tǒng)的容量模型和容量設(shè)計，是一個很復(fù)雜且很困難的事情，但是需要再內(nèi)部測試環(huán)境盡可能的模擬和壓測，能夠得到一定的參考依據(jù)，生產(chǎn)上能夠得到一定的參考數(shù)據(jù)。

• 核心鏈路混沌演練
  只要真正生產(chǎn)的演練，才能發(fā)現(xiàn)問題，紙面上的理論驗證都不如實際的操作演練，問題才能真正的暴露。

6.2 雞蛋不要放在一個籃子里

核心鏈路的數(shù)據(jù)、部署等，盡可能的做拆分，在系統(tǒng)架構(gòu)上，我傾向于去中心化這個概念。在關(guān)鍵的容災(zāi)上，往往能夠起到意想不到的效果

6.3 淘汰糟糕的iaas設(shè)備

• 淘汰糟糕的iaas設(shè)備
  在生產(chǎn)環(huán)境上，導(dǎo)致分布式組件異常的，90%以上的因素來自糟糕的iaas設(shè)備，而不是來自分布式組件本身的邏輯設(shè)計bug，特別是開源的組件，都是久經(jīng)考驗，大體上還是比較有保證的。一個良好的設(shè)備，并不是說要購買幾百萬一臺的超級設(shè)備，至少設(shè)備本身不應(yīng)該經(jīng)常性的出問題（時不時磁盤壞了，內(nèi)存異常，頻繁關(guān)機(jī)等）。日常需要加強(qiáng)相關(guān)的監(jiān)控和告警，異常率高的iaas設(shè)備應(yīng)該及時淘汰，淘汰糟糕的iaas設(shè)備，至少能夠規(guī)避90%以上的故障（有條件的情況下，更傾向于疑罪從有策略）

6.4 更完善的監(jiān)控和告警

• 核心系統(tǒng)全鏈路監(jiān)控和告警
  需要包括核心鏈路的監(jiān)控大盤和告警，特別是核心鏈路建議增加核心鏈路環(huán)節(jié)的全鏈路告警。
  在告警的建設(shè)上要抓大放小，把重要的精力都放在重點問題的建設(shè)上，抓重點，多建設(shè)全鏈路監(jiān)控

• 組件監(jiān)控+iaas監(jiān)控

• 深入業(yè)務(wù)邏輯， 構(gòu)建業(yè)務(wù)監(jiān)控大盤

7. 參考文檔

Raft常見選主邏輯文章來源地址http://www.zghlxwxcb.cn/news/detail-810970.html

到了這里，關(guān)于關(guān)于常見分布式組件高可用設(shè)計原理的理解和思考的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！