寫在前面

在當今信息爆炸的時代，單臺計算機已經(jīng)無法負載日益增長的業(yè)務發(fā)展，雖然也有性能強大的超級計算機，但是這種高端機不僅費用高昂，也不靈活，一般的企業(yè)是負擔不起的，而且也損失不起，那么將一群廉價的普通計算機組合起來，讓它們協(xié)同工作就像一臺超級計算機一樣地對外提供服務，就成了順其自然的設想，但是這又增加了軟件的復雜度，要求開發(fā)的軟件需要具備橫向擴展能力，比如：Kafka、Elasticsearch、Zookeeper等就屬于這一類軟件，它們天生都是"分布式的"，即可以通過添加機器節(jié)點來共同地分攤數(shù)據(jù)存儲和負載壓力。

為什么需要集群?

分布在不同區(qū)域的計算機，彼此之間通過網(wǎng)絡建立通信，相互協(xié)作作為一個整體對外提供服務，這就是集群，如果我們開發(fā)的系統(tǒng)具備這樣的能力，那么理論上就具備***橫向擴容的能力，系統(tǒng)的吞吐量就會隨著機器數(shù)增加而增長，那么未來當系統(tǒng)出現(xiàn)高負載的時候，就可以很好地應對這種情況。

[[236565]]

為什么CAP不能同時滿足?

通過上面分析，我們知道實現(xiàn)集群，其實就是采用多臺計算機來共同承擔和負載系統(tǒng)壓力，那么就涉及到多臺計算機需要參與一起處理數(shù)據(jù)，為了保證可用性，一般都會在每臺計算機上備份一份數(shù)據(jù)，這樣只要有一個節(jié)點保持同步狀態(tài)，那么數(shù)據(jù)就不會丟失，比如kafka分區(qū)多副本、Elasticsearch的副本分片，由于同一數(shù)據(jù)塊及其副本位于不用的機器，隨著時間的推移，再加上不可靠的網(wǎng)絡通信，所有機器上的數(shù)據(jù)必然會不完全一致，這個時候假如發(fā)生一種極端情況，所有的機器宕機了，又如何保證數(shù)據(jù)不丟失呢(其實只有兩種方法)?

1、保證可用性：選擇***臺恢復正常服務的機器(不一定擁有全部數(shù)據(jù))作為可信的數(shù)據(jù)來源，快速恢復集群，即停機時間優(yōu)于同步。

2、保證數(shù)據(jù)一致性：等待***臺擁有全部數(shù)據(jù)的機器恢復正常，再恢復集群，即同步優(yōu)于停機時間，比如禁用kafka的unclean leader選舉機制就是這種策略。

其實當大多數(shù)機器不可用時，就需要在可用性和一致性之間進行妥協(xié)了，所以另一個更符合分布式系統(tǒng)的Base理論又被創(chuàng)造出來了。

如何解決分布式存儲問題?

當由多臺計算機組成的集群對外提供服務時，其實就是對外提供讀、寫的能力。

數(shù)據(jù)塊技術(data block)

為了將數(shù)據(jù)合理、均勻地寫到各個機器上，提高集群寫能力;為了將讀請求負載均衡到不同的節(jié)點，提高集群的讀能力;為了解耦數(shù)據(jù)存儲和物理節(jié)點，提高分布式讀寫并行處理的能力，聰明的工程師引入了一個邏輯數(shù)據(jù)存儲單位，統(tǒng)稱為數(shù)據(jù)塊，比如Kafka的分區(qū)(partion)、Elasticsearch的分片(shard)，這樣的虛擬化大大提高了集群讀寫的靈活性。

備注：所以啊，名字不重要，知其所以然最重要。

協(xié)調節(jié)點(coordination node)

實際上當集群作為一個整體處理數(shù)據(jù)時，可能每一個節(jié)點都會收到讀寫請求，但是數(shù)據(jù)又是分散在不同的節(jié)點上，所以就需要每個節(jié)點都清楚地知道集群中任意一個數(shù)據(jù)塊的位置，然后再將請求轉發(fā)到相應的節(jié)點，這就是“協(xié)調節(jié)點”的工作。比如：Elasticsearch的master節(jié)點管理集群范圍內的所有變更，主分片管理數(shù)據(jù)塊范圍內的所有變更。

大多數(shù)投票機制(quorum)

百度百科：quorum，翻譯法定人數(shù)，指舉行會議、通過議案、進行選舉或組織某種專門機構時，法律所規(guī)定的必要人數(shù)，未達法定人數(shù)無效。

由于網(wǎng)絡分區(qū)的存在，這個機制被廣泛地應用于分布式系統(tǒng)中，比如集群節(jié)點之間選舉Master;數(shù)據(jù)塊之間選舉Header等;在分布式存儲中，也被稱為Quorum讀寫機制，即寫入的時候，保證大多數(shù)節(jié)點都寫入成功(一般的做法會選舉一個主數(shù)據(jù)塊(header)，保證它寫成功，然后再同步到冗余的副本數(shù)據(jù)塊);讀取的時候保證讀取大多數(shù)節(jié)點的數(shù)據(jù)(一般的做法是由協(xié)調節(jié)點分發(fā)請求到不同的節(jié)點，然后將所有檢索到的數(shù)據(jù)進行全局匯總排序后再返回);由于讀寫都是大多數(shù)，那么中間肯定存在***的重疊數(shù)據(jù)，這樣就能保證一定能讀到***的數(shù)據(jù)。

從上面分析可以得出，只要大多數(shù)節(jié)點處于活躍可用狀態(tài)，那么整個集群的可用性就不會受到影響;只要大多數(shù)據(jù)塊處于活躍可用的狀態(tài)，那么就能持續(xù)地提供讀寫服務;只要有一個數(shù)據(jù)塊完成了同步狀態(tài)，那么數(shù)據(jù)就不會丟失;這其實就是通過一種冗余機制來嘗試處理fail/recover模式的故障，通俗點講就是容忍單點故障，至少需要部署3個節(jié)點;容忍2點故障，至少需要部署5個節(jié)點，機器節(jié)點越多分區(qū)容忍性就越強，頓悟了吧，嘿嘿，所以保證集群可用的前提就是有奇數(shù)個節(jié)點、奇數(shù)個數(shù)據(jù)塊保持活躍可用狀態(tài)，不然就無法選舉出master或header。

大多數(shù)投票機制運用起來也非常靈活，當分布式系統(tǒng)追求強一致性時，需要等待所有的數(shù)據(jù)快及其副本全部寫入成功才算完成一次寫操作，即寫全部(write all)，可以理解一種事務保證，要么全部寫入，要么一個都不寫入，比如：kafka從0.11.0.0 版本開始， 當producer發(fā)送消息到多個topic partion時，就運用了這種機制，來保證消息交付的exactly-once語義，是不是很帥，而且這種情況下，從任意一個節(jié)點都能讀到***的數(shù)據(jù)，讀性能***;當分布式系統(tǒng)追求最終一致性時，只需等待主數(shù)據(jù)塊(leader)寫入成功即可，再由主數(shù)據(jù)塊通過消息可達的方式同步到副本數(shù)據(jù)塊。

為了能夠滿足不同場景下對數(shù)據(jù)可靠性和系統(tǒng)吞吐量的要求，***化數(shù)據(jù)持久性和系統(tǒng)可用性，很多組件都提供了配置項，允許用戶定義這個大多數(shù)的法定數(shù)量，下面我們就來談談一些常用組件的配置：

Elasticsearch 

由上圖可以看到，整個集群由三個運行了Elasticsearch實例的節(jié)點組成，有兩個主分片，每個分片又有兩個副分片，總共有6個分片拷貝，Elasticsearch內部自動將相同的分片放到了不同的節(jié)點，非常合理和理想。當我們新建一個文檔時：

1、客戶端向 Node 1 發(fā)送新建文檔的寫請求。

2、節(jié)點使用文檔的 _id 確定文檔屬于分片 0 。請求會被轉發(fā)到 Node 3，因為分片 0 的主分片目前被分配在 Node 3 上。

3、Node 3 在主分片上面執(zhí)行請求。如果成功了，它將請求并行轉發(fā)到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都報告成功, Node 3 將向協(xié)調節(jié)點報告成功，協(xié)調節(jié)點向客戶端報告成功。

這就是Elasticsearch處理寫請求的典型步驟順序，同時每種業(yè)務場景對數(shù)據(jù)可靠性的要求和系統(tǒng)性能也不一樣，所以Elasticsearch提供了Consistence配置項：

1、one：主分片處于活躍可用狀態(tài)就可以處理寫請求。系統(tǒng)吞吐量***，但數(shù)據(jù)可能會丟失，對數(shù)據(jù)可靠性要求不是很高的場景非常適合，比如實時的時序數(shù)據(jù)處理(日志)。

2、all：主分片和所有副本分片處于活躍可用狀態(tài)才允許處理寫請求。系統(tǒng)吞吐量***，但數(shù)據(jù)不會丟失。處理關鍵的業(yè)務數(shù)據(jù)非常合適。

3、quorum：必須有大多數(shù)的分片拷貝處于活躍可用狀態(tài)才允許處理寫請求。平衡系統(tǒng)吞吐量和數(shù)據(jù)可靠性，一般業(yè)務系統(tǒng)都使用這個配置。

Kafka

當向Kafka 寫數(shù)據(jù)時，producers可以通過設置ack來自定義數(shù)據(jù)可靠性的級別：

0：不等待broker返回確認消息。

1: leader保存成功返回。

-1(all): 所有備份都保存成功返回。

備注：默認情況下，為了保證分區(qū)的***可用性，當acks=all時，只要ISR集合中的副本分區(qū)寫入成功，kafka就會返回消息寫入成功。如果要真正地保證寫全部(write all)，那么我們需要更改配置transaction.state.log.min.isr來指定topic最小的ISR集合大小，即設置ISR集合長度等于topic的分區(qū)數(shù)。

如果所有的節(jié)點都掛掉，還有Unclean leader選舉機制的保證，建議大家下去閱讀kafka《官方指南》設計部分，深入理解kafka是如何通過引入ISR集合來變通大多數(shù)投票機制，從而更好地保證消息交付的不同語義。

什么是集群腦裂?

對于分布式系統(tǒng)，自動處理故障的關鍵就是能夠精準地知道節(jié)點的存活狀態(tài)(alive)。有時候，節(jié)點不可用，不一定就是其本身掛掉了，極有可能是暫時的網(wǎng)絡故障;在這種情況下，如果馬上選舉一個master節(jié)點，那么等到網(wǎng)絡通信恢復正常的時候，豈不是同時存在兩個master，這種現(xiàn)象被形象地稱為“集群腦裂”，先留給大家下去思考吧。呵呵，明天要早起，碎覺了，大家晚安。

備注：設計一個正在高可用的分布式系統(tǒng)，需要考慮的故障情況往往會很復雜，大多數(shù)組件都只是處理了fail/recover模式的故障，即容忍一部分節(jié)點不可用，然后等待恢復;并不能處理拜占庭故障(Byzantine)，即節(jié)點間的信任問題，也許區(qū)塊鏈可以解決吧，大家可以下去多多研究，然后我們一起討論，共同學習，一起進步。

寫在***

分享了這么多，請大家總結一下大多數(shù)投票機制的優(yōu)點和缺點?歡迎評論區(qū)留言，哈哈，真的要睡覺了，晚安。