寫在前面
在當今資訊爆炸的時代，單臺計算機已經無法負載日益增長的業務發展，雖然也有性能強大的超級計算機，但是這種高端機不僅費用高昂，也不靈活，一般的企業是負擔不起的，而且也損失不起，那么將一群廉價的普通計算機組合起來，讓它們協同作業就像一臺超級計算機一樣地對外提供服務，就成了順其自然的設想，但是這又增加了軟體的復雜度，要求開發的軟體需要具備橫向擴展能力，比如：Kafka、Elasticsearch、Zookeeper等就屬于這一類軟體，它們天生都是"分布式的"，即可以通過添加機器節點來共同地分攤資料存盤和負載壓力，
為什么需要集群？
分布在不同區域的計算機，彼此之間通過網路建立通信，相互協作作為一個整體對外提供服務，這就是集群，如果我們開發的系統具備這樣的能力，那么理論上就具備無限橫向擴容的能力，系統的吞吐量就會隨著機器數增加而增長，那么未來當系統出現高負載的時候，就可以很好地應對這種情況，
為什么CAP不能同時滿足？
通過上面分析，我們知道實作集群，其實就是采用多臺計算機來共同承擔和負載系統壓力，那么就涉及到多臺計算機需要參與一起處理資料，為了保證可用性，一般都會在每臺計算機上備份一份資料，這樣只要有一個節點保持同步狀態，那么資料就不會丟失，比如kafka磁區多副本、Elasticsearch的副本分片，由于同一資料塊及其副本位于不用的機器，隨著時間的推移，再加上不可靠的網路通信，所有機器上的資料必然會不完全一致，這個時候假如發生一種極端情況，所有的機器宕機了，又如何保證資料不丟失呢（其實只有兩種方法）？
-
保證可用性：選擇第一臺恢復正常服務的機器（不一定擁有全部資料）作為可信的資料來源，快速恢復集群，即停機時間優于同步，
-
保證資料一致性：等待第一臺擁有全部資料的機器恢復正常，再恢復集群，即同步優于停機時間，比如禁用kafka的unclean leader選舉機制就是這種策略，
其實當大多數機器不可用時，就需要在可用性和一致性之間進行妥協了，所以另一個更符合分布式系統的Base理論又被創造出來了，
如何解決分布式存盤問題？
當由多臺計算機組成的集群對外提供服務時，其實就是對外提供讀、寫的能力，
1.資料塊技術（data block）
為了將資料合理、均勻地寫到各個機器上，提高集群寫能力；為了將讀請求負載均衡到不同的節點，提高集群的讀能力；為了解耦資料存盤和物理節點，提高分布式讀寫并行處理的能力，聰明的工程師引入了一個邏輯資料存盤單位，統稱為資料塊，比如Kafka的磁區(partion)、Elasticsearch的分片(shard)，這樣的虛擬化大大提高了集群讀寫的靈活性，
2.協調節點（coordination node）
實際上當集群作為一個整體處理資料時，可能每一個節點都會收到讀寫請求，但是資料又是分散在不同的節點上，所以就需要每個節點都清楚地知道集群中任意一個資料塊的位置，然后再將請求轉發到相應的節點，這就是“協調節點”的作業，比如：Elasticsearch的master節點管理集群范圍內的所有變更，主分片管理資料塊范圍內的所有變更，
3.大多數投票機制（quorum）
百度百科：quorum，翻譯法定人數，指舉行會議、通過議案、進行選舉或組織某種專門機構時，法律所規定的必要人數，未達法定人數無效，
由于網路磁區的存在，這個機制被廣泛地應用于分布式系統中，比如集群節點之間選舉Master；資料塊之間選舉Header等；在分布式存盤中，也被稱為Quorum讀寫機制，即寫入的時候，保證大多數節點都寫入成功（一般的做法會選舉一個主資料塊(header)，保證它寫成功，然后再同步到冗余的副本資料塊）；讀取的時候保證讀取大多數節點的資料（一般的做法是由協調節點分發請求到不同的節點，然后將所有檢索到的資料進行全域匯總排序后再回傳）；由于讀寫都是大多數，那么中間肯定存在最新的重疊資料，這樣就能保證一定能讀到最新的資料，
從上面分析可以得出，只要大多數節點處于活躍可用狀態，那么整個集群的可用性就不會受到影響；只要大多資料塊處于活躍可用的狀態，那么就能持續地提供讀寫服務；只要有一個資料塊完成了同步狀態，那么資料就不會丟失；這其實就是通過一種冗余機制來嘗試處理fail/recover模式的故障，通俗點講就是容忍單點故障，至少需要部署3個節點；容忍2點故障，至少需要部署5個節點，機器節點越多磁區容忍性就越強，即通過增加機器數來降低由于機器故障影響服務的概率，頓悟了吧，嘿嘿，所以保證集群可用的前提就是有奇數個節點、奇數個資料塊保持活躍可用狀態，不然就無法選舉出master或header，
大多數投票機制運用起來也非常靈活，當分布式系統追求強一致性時，需要等待所有的資料快及其副本全部寫入成功才算完成一次寫操作，即寫全部(write all)，可以理解一種事務保證，要么全部寫入，要么一個都不寫入，比如：kafka從0.11.0.0 版本開始， 當producer發送訊息到多個topic partion時，就運用了這種機制，來保證訊息交付的exactly-once語意，是不是很帥，而且這種情況下，從任意一個節點都能讀到最新的資料，讀性能最高；當分布式系統追求最終一致性時，只需等待主資料塊(leader)寫入成功即可，再由主資料塊通過訊息可達的方式同步到副本資料塊，
為了能夠滿足不同場景下對資料可靠性和系統吞吐量的要求，最大化資料持久性和系統可用性，很多組件都提供了配置項，允許用戶定義這個大多數的法定數量，下面我們就來談談一些常用組件的配置：
Elasticsearch
由上圖可以看到，整個集群由三個運行了Elasticsearch實體的節點組成，有兩個主分片，每個分片又有兩個副分片，總共有6個分片拷貝，Elasticsearch內部自動將相同的分片放到了不同的節點，非常合理和理想，
當我們新建一個檔案時：
-
客戶端向 Node 1 發送新建檔案的寫請求，
-
節點使用檔案的 _id 確定檔案屬于分片 0 ，請求會被轉發到 Node 3，因為分片 0 的主分片目前被分配在 Node 3 上，
-
Node 3 在主分片上面執行請求，如果成功了，它將請求并行轉發到 Node 1 和 Node 2 的副本分片上，一旦所有的副本分片都報告成功, Node 3 將向協調節點報告成功，協調節點向客戶端報告成功，
這就是Elasticsearch處理寫請求的典型步驟順序，同時每種業務場景對資料可靠性的要求和系統性能也不一樣，所以Elasticsearch提供了Consistence配置項：
-
one：主分片處于活躍可用狀態就可以處理寫請求，
系統吞吐量最高，但資料可能會丟失，對資料可靠性要求不是很高的場景非常適合，比如實時的時序資料處理（日志），
-
all：主分片和所有副本分片處于活躍可用狀態才允許處理寫請求，
系統吞吐量最低，但資料不會丟失，處理關鍵的業務資料非常合適，
-
quorum：必須有大多數的分片拷貝處于活躍可用狀態才允許處理寫請求，
平衡系統吞吐量和資料可靠性，一般業務系統都使用這個配置，
Kafka
當向Kafka 寫資料時，producers可以通過設定ack來自定義資料可靠性的級別：
-
0：不等待broker回傳確認訊息，
-
1: leader保存成功回傳，
-
-1(all): 所有備份都保存成功回傳，
備注：默認情況下，為了保證磁區的最大可用性，當acks=all時，只要ISR集合中的副本磁區寫入成功，kafka就會回傳訊息寫入成功，如果要真正地保證寫全部(write all)，那么我們需要更改配置transaction.state.log.min.isr來指定topic最小的ISR集合大小，即設定ISR集合長度等于topic的磁區數，
如果所有的節點都掛掉，還有Unclean leader選舉機制的保證，建議大家下去閱讀kafka《官方指南》設計部分，深入理解kafka是如何通過引入ISR集合來變通大多數投票機制，從而更好地保證訊息交付的不同語意，
什么是集群腦裂？
對于分布式系統，自動處理故障的關鍵就是能夠精準地知道節點的存活狀態(alive)，有時候，節點不可用，不一定就是其本身掛掉了，極有可能是暫時的網路故障；在這種情況下，如果馬上選舉一個master節點，那么等到網路通信恢復正常的時候，豈不是同時存在兩個master，這種現象被形象地稱為“集群腦裂”，先留給大家下去思考吧，呵呵，明天要早起，碎覺了，大家晚安，
備注：設計一個正在高可用的分布式系統，需要考慮的故障情況往往會很復雜，大多陣列件都只是處理了fail/recover模式的故障，即容忍一部分節點不可用，然后等待恢復；并沒有處理拜占庭故障(Byzantine)，即節點間的信任問題，也許區塊鏈可以解決吧，大家可以下去多多研究，然后我們一起討論，共同學習，一起進步，
補充：大多數投票機制的優缺點
優點
大多數投票機制延遲取決于最快的服務器，即等待資料備份完成的等待時間取決于最快的follower，比如副本因子是3，header占據1位，再有1位最快的follower同步完成，就滿足大多數了，
缺點
大多數(n+1)的節點掛掉就無法選舉leader，從而整個集群徹底失去可用性，比如：為了冗余單點故障，通常需要三個節點備份資料，但是當其中兩臺掛掉時，整個集群就掛了，僅僅靠冗余資料來避免單點故障是不夠，通常對磁盤空間需求量為2n+1倍，相應地也會導致寫吞吐量下降2n+1倍，這種高昂的存盤方式并不適合存盤原始資料，這就是為什么quorum演算法更適合共享集群配置資料，如zookeeper，這也是kafka為什么要引入一個同步狀態備份集合(ISR)，通過降低所需的備份資料而帶來額外的吞吐量和磁盤空間，從而提高kafka處理海量實時資料的能力，
有需要學習交流的友人請加入交流群的咱們一起，群內都是1-7年的開發者，希望可以一起交流，探討PHP,swoole這塊的技術 或者有其他問題 也可以問，獲取swoole或者php進階相關資料私聊管理即可
點此加入該群?jq.qq.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/88087.html
標籤：PHP
上一篇：一個PHP的SQL注入完整程序