必須理解的分布式系統(tǒng)中雷同集群技術(shù)及原理
寫在前面
在當(dāng)今信息爆炸的時代,單臺計算機(jī)已經(jīng)無法負(fù)載日益增長的業(yè)務(wù)發(fā)展,雖然也有性能強(qiáng)大的超級計算機(jī),但是這種高端機(jī)不僅費(fèi)用高昂,也不靈活,一般的企業(yè)是負(fù)擔(dān)不起的,而且也損失不起,那么將一群廉價的普通計算機(jī)組合起來,讓它們協(xié)同工作就像一臺超級計算機(jī)一樣地對外提供服務(wù),就成了順其自然的設(shè)想,但是這又增加了軟件的復(fù)雜度,要求開發(fā)的軟件需要具備橫向擴(kuò)展能力,比如:Kafka、Elasticsearch、Zookeeper等就屬于這一類軟件,它們天生都是"分布式的",即可以通過添加機(jī)器節(jié)點(diǎn)來共同地分?jǐn)倲?shù)據(jù)存儲和負(fù)載壓力。
為什么需要集群?
分布在不同區(qū)域的計算機(jī),彼此之間通過網(wǎng)絡(luò)建立通信,相互協(xié)作作為一個整體對外提供服務(wù),這就是集群,如果我們開發(fā)的系統(tǒng)具備這樣的能力,那么理論上就具備***橫向擴(kuò)容的能力,系統(tǒng)的吞吐量就會隨著機(jī)器數(shù)增加而增長,那么未來當(dāng)系統(tǒng)出現(xiàn)高負(fù)載的時候,就可以很好地應(yīng)對這種情況。
為什么CAP不能同時滿足?
通過上面分析,我們知道實(shí)現(xiàn)集群,其實(shí)就是采用多臺計算機(jī)來共同承擔(dān)和負(fù)載系統(tǒng)壓力,那么就涉及到多臺計算機(jī)需要參與一起處理數(shù)據(jù),為了保證可用性,一般都會在每臺計算機(jī)上備份一份數(shù)據(jù),這樣只要有一個節(jié)點(diǎn)保持同步狀態(tài),那么數(shù)據(jù)就不會丟失,比如kafka分區(qū)多副本、Elasticsearch的副本分片,由于同一數(shù)據(jù)塊及其副本位于不用的機(jī)器,隨著時間的推移,再加上不可靠的網(wǎng)絡(luò)通信,所有機(jī)器上的數(shù)據(jù)必然會不完全一致,這個時候假如發(fā)生一種極端情況,所有的機(jī)器宕機(jī)了,又如何保證數(shù)據(jù)不丟失呢(其實(shí)只有兩種方法)?
1、保證可用性:選擇***臺恢復(fù)正常服務(wù)的機(jī)器(不一定擁有全部數(shù)據(jù))作為可信的數(shù)據(jù)來源,快速恢復(fù)集群,即停機(jī)時間優(yōu)于同步。
2、保證數(shù)據(jù)一致性:等待***臺擁有全部數(shù)據(jù)的機(jī)器恢復(fù)正常,再恢復(fù)集群,即同步優(yōu)于停機(jī)時間,比如禁用kafka的unclean leader選舉機(jī)制就是這種策略。
其實(shí)當(dāng)大多數(shù)機(jī)器不可用時,就需要在可用性和一致性之間進(jìn)行妥協(xié)了,所以另一個更符合分布式系統(tǒng)的Base理論又被創(chuàng)造出來了。
如何解決分布式存儲問題?
當(dāng)由多臺計算機(jī)組成的集群對外提供服務(wù)時,其實(shí)就是對外提供讀、寫的能力。
數(shù)據(jù)塊技術(shù)(data block)
為了將數(shù)據(jù)合理、均勻地寫到各個機(jī)器上,提高集群寫能力;為了將讀請求負(fù)載均衡到不同的節(jié)點(diǎn),提高集群的讀能力;為了解耦數(shù)據(jù)存儲和物理節(jié)點(diǎn),提高分布式讀寫并行處理的能力,聰明的工程師引入了一個邏輯數(shù)據(jù)存儲單位,統(tǒng)稱為數(shù)據(jù)塊,比如Kafka的分區(qū)(partion)、Elasticsearch的分片(shard),這樣的虛擬化大大提高了集群讀寫的靈活性。
備注:所以啊,名字不重要,知其所以然最重要。
協(xié)調(diào)節(jié)點(diǎn)(coordination node)
實(shí)際上當(dāng)集群作為一個整體處理數(shù)據(jù)時,可能每一個節(jié)點(diǎn)都會收到讀寫請求,但是數(shù)據(jù)又是分散在不同的節(jié)點(diǎn)上,所以就需要每個節(jié)點(diǎn)都清楚地知道集群中任意一個數(shù)據(jù)塊的位置,然后再將請求轉(zhuǎn)發(fā)到相應(yīng)的節(jié)點(diǎn),這就是“協(xié)調(diào)節(jié)點(diǎn)”的工作。比如:Elasticsearch的master節(jié)點(diǎn)管理集群范圍內(nèi)的所有變更,主分片管理數(shù)據(jù)塊范圍內(nèi)的所有變更。
大多數(shù)投票機(jī)制(quorum)
百度百科:quorum,翻譯法定人數(shù),指舉行會議、通過議案、進(jìn)行選舉或組織某種專門機(jī)構(gòu)時,法律所規(guī)定的必要人數(shù),未達(dá)法定人數(shù)無效。
由于網(wǎng)絡(luò)分區(qū)的存在,這個機(jī)制被廣泛地應(yīng)用于分布式系統(tǒng)中,比如集群節(jié)點(diǎn)之間選舉Master;數(shù)據(jù)塊之間選舉Header等;在分布式存儲中,也被稱為Quorum讀寫機(jī)制,即寫入的時候,保證大多數(shù)節(jié)點(diǎn)都寫入成功(一般的做法會選舉一個主數(shù)據(jù)塊(header),保證它寫成功,然后再同步到冗余的副本數(shù)據(jù)塊);讀取的時候保證讀取大多數(shù)節(jié)點(diǎn)的數(shù)據(jù)(一般的做法是由協(xié)調(diào)節(jié)點(diǎn)分發(fā)請求到不同的節(jié)點(diǎn),然后將所有檢索到的數(shù)據(jù)進(jìn)行全局匯總排序后再返回);由于讀寫都是大多數(shù),那么中間肯定存在***的重疊數(shù)據(jù),這樣就能保證一定能讀到***的數(shù)據(jù)。
從上面分析可以得出,只要大多數(shù)節(jié)點(diǎn)處于活躍可用狀態(tài),那么整個集群的可用性就不會受到影響;只要大多數(shù)據(jù)塊處于活躍可用的狀態(tài),那么就能持續(xù)地提供讀寫服務(wù);只要有一個數(shù)據(jù)塊完成了同步狀態(tài),那么數(shù)據(jù)就不會丟失;這其實(shí)就是通過一種冗余機(jī)制來嘗試處理fail/recover模式的故障,通俗點(diǎn)講就是容忍單點(diǎn)故障,至少需要部署3個節(jié)點(diǎn);容忍2點(diǎn)故障,至少需要部署5個節(jié)點(diǎn),機(jī)器節(jié)點(diǎn)越多分區(qū)容忍性就越強(qiáng),頓悟了吧,嘿嘿,所以保證集群可用的前提就是有奇數(shù)個節(jié)點(diǎn)、奇數(shù)個數(shù)據(jù)塊保持活躍可用狀態(tài),不然就無法選舉出master或header。
大多數(shù)投票機(jī)制運(yùn)用起來也非常靈活,當(dāng)分布式系統(tǒng)追求強(qiáng)一致性時,需要等待所有的數(shù)據(jù)快及其副本全部寫入成功才算完成一次寫操作,即寫全部(write all),可以理解一種事務(wù)保證,要么全部寫入,要么一個都不寫入,比如:kafka從0.11.0.0 版本開始, 當(dāng)producer發(fā)送消息到多個topic partion時,就運(yùn)用了這種機(jī)制,來保證消息交付的exactly-once語義,是不是很帥,而且這種情況下,從任意一個節(jié)點(diǎn)都能讀到***的數(shù)據(jù),讀性能***;當(dāng)分布式系統(tǒng)追求最終一致性時,只需等待主數(shù)據(jù)塊(leader)寫入成功即可,再由主數(shù)據(jù)塊通過消息可達(dá)的方式同步到副本數(shù)據(jù)塊。
為了能夠滿足不同場景下對數(shù)據(jù)可靠性和系統(tǒng)吞吐量的要求,***化數(shù)據(jù)持久性和系統(tǒng)可用性,很多組件都提供了配置項(xiàng),允許用戶定義這個大多數(shù)的法定數(shù)量,下面我們就來談?wù)勔恍┏S媒M件的配置:
Elasticsearch
由上圖可以看到,整個集群由三個運(yùn)行了Elasticsearch實(shí)例的節(jié)點(diǎn)組成,有兩個主分片,每個分片又有兩個副分片,總共有6個分片拷貝,Elasticsearch內(nèi)部自動將相同的分片放到了不同的節(jié)點(diǎn),非常合理和理想。當(dāng)我們新建一個文檔時:
1、客戶端向 Node 1 發(fā)送新建文檔的寫請求。
2、節(jié)點(diǎn)使用文檔的 _id 確定文檔屬于分片 0 。請求會被轉(zhuǎn)發(fā)到 Node 3,因?yàn)榉制?0 的主分片目前被分配在 Node 3 上。
3、Node 3 在主分片上面執(zhí)行請求。如果成功了,它將請求并行轉(zhuǎn)發(fā)到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都報告成功, Node 3 將向協(xié)調(diào)節(jié)點(diǎn)報告成功,協(xié)調(diào)節(jié)點(diǎn)向客戶端報告成功。
這就是Elasticsearch處理寫請求的典型步驟順序,同時每種業(yè)務(wù)場景對數(shù)據(jù)可靠性的要求和系統(tǒng)性能也不一樣,所以Elasticsearch提供了Consistence配置項(xiàng):
1、one:主分片處于活躍可用狀態(tài)就可以處理寫請求。系統(tǒng)吞吐量***,但數(shù)據(jù)可能會丟失,對數(shù)據(jù)可靠性要求不是很高的場景非常適合,比如實(shí)時的時序數(shù)據(jù)處理(日志)。
2、all:主分片和所有副本分片處于活躍可用狀態(tài)才允許處理寫請求。系統(tǒng)吞吐量***,但數(shù)據(jù)不會丟失。處理關(guān)鍵的業(yè)務(wù)數(shù)據(jù)非常合適。
3、quorum:必須有大多數(shù)的分片拷貝處于活躍可用狀態(tài)才允許處理寫請求。平衡系統(tǒng)吞吐量和數(shù)據(jù)可靠性,一般業(yè)務(wù)系統(tǒng)都使用這個配置。
Kafka
當(dāng)向Kafka 寫數(shù)據(jù)時,producers可以通過設(shè)置ack來自定義數(shù)據(jù)可靠性的級別:
0:不等待broker返回確認(rèn)消息。
1: leader保存成功返回。
-1(all): 所有備份都保存成功返回。
備注:默認(rèn)情況下,為了保證分區(qū)的***可用性,當(dāng)acks=all時,只要ISR集合中的副本分區(qū)寫入成功,kafka就會返回消息寫入成功。如果要真正地保證寫全部(write all),那么我們需要更改配置transaction.state.log.min.isr來指定topic最小的ISR集合大小,即設(shè)置ISR集合長度等于topic的分區(qū)數(shù)。
如果所有的節(jié)點(diǎn)都掛掉,還有Unclean leader選舉機(jī)制的保證,建議大家下去閱讀kafka《官方指南》設(shè)計部分,深入理解kafka是如何通過引入ISR集合來變通大多數(shù)投票機(jī)制,從而更好地保證消息交付的不同語義。
什么是集群腦裂?
對于分布式系統(tǒng),自動處理故障的關(guān)鍵就是能夠精準(zhǔn)地知道節(jié)點(diǎn)的存活狀態(tài)(alive)。有時候,節(jié)點(diǎn)不可用,不一定就是其本身掛掉了,極有可能是暫時的網(wǎng)絡(luò)故障;在這種情況下,如果馬上選舉一個master節(jié)點(diǎn),那么等到網(wǎng)絡(luò)通信恢復(fù)正常的時候,豈不是同時存在兩個master,這種現(xiàn)象被形象地稱為“集群腦裂”,先留給大家下去思考吧。呵呵,明天要早起,碎覺了,大家晚安。
備注:設(shè)計一個正在高可用的分布式系統(tǒng),需要考慮的故障情況往往會很復(fù)雜,大多數(shù)組件都只是處理了fail/recover模式的故障,即容忍一部分節(jié)點(diǎn)不可用,然后等待恢復(fù);并不能處理拜占庭故障(Byzantine),即節(jié)點(diǎn)間的信任問題,也許區(qū)塊鏈可以解決吧,大家可以下去多多研究,然后我們一起討論,共同學(xué)習(xí),一起進(jìn)步。
寫在***
分享了這么多,請大家總結(jié)一下大多數(shù)投票機(jī)制的優(yōu)點(diǎn)和缺點(diǎn)?歡迎評論區(qū)留言,哈哈,真的要睡覺了,晚安。