分佈式系統的經典理論

分佈式系統從誕生到現在已經有幾十個年頭了，其中伴隨着一些很重要的基礎理論，正是這些影響深遠的基礎理論，奠定了分佈式系統的堅實基礎，造就了分佈式領域的一座座宏偉大廈。爲了練就一身武功，讓我們從這些經典的分佈式理論開始學起吧。

從分佈式系統的設計理念說起

分佈式系統的首要目標是提升系統的整體性能和吞吐量。如果最終設計出來的分佈式系統佔用了 10 臺機器才勉強達到單機系統的兩倍性能, 那麼這個分佈式系統還有存在的價值嗎? 另外，即使採用了分佈式架構，也仍然需要盡力提升單機上的程序性能，使得整體性能達到最高。所以，我們仍然需要掌握高性能單機程序的設計和編程技巧，例如多線程併發編程、多進程高性能 IPC 通信、高性能的網絡框架等。

另外，任何分佈式系統都存在讓人無法迴避的風險和嚴重問題，即系統發生故障的概率大大增加: 小到一臺服務器的硬盤發生故障或宕機、一根網線壞掉，大到一臺交換機甚至幾十臺服務器一起停機。分佈式系統下故障概率的增加，除了受到網絡通信天生的不可靠性及物理上分佈部署的影響，還受到 X86 服務器品質等的影響。

所以，分佈式系統設計的兩大關鍵目標是性能與容錯性，而這兩個目標的實現恰恰是很棘手的，而且相互羈絆! 舉個例子，我們要設計一個分佈式存儲系統，出於對性能的考慮，在寫文件時要先寫一個副本到某臺機器上並立即返回，然後異步發起多副本的複製過程，這種設計的性能最好，但存在 “容錯性” 的風險，即在文件寫完後，目標機器立即發生故障，導致文件丟失! 如果同時寫多個副本，在每個副本都成功以後再返回，則又導致 “性能” 下降，因爲該過程取決於最慢的那臺機器的性能。

由於性能指標是絕對的，而容錯性指標是相對的，而且實際上對於不同的數據與業務，我們要求的容錯性可以存在很大的差異，比如允許意外丟失一些日誌類的數據; 允許一些信息類的數據暫時不一致但最終達到一致; 對交易類的數據要求有很高的可靠性。所以我們會發現，很多分佈式系統的設計都提供了多種容錯性策略，以適應不同的業務場景，我們在學習和設計分佈式系統的過程中也需要注意這一特性。

下面繼續談談分佈式系統設計中的兩大思路: 中心化和去中心化。

在分佈式架構設計裏，中心化始終是一個主流設計。中心化的設計思想很簡單，分佈式集羣中的節點器按照角色分工，大體上分爲兩種角色: Leader 和 Worker。Leader 通常負責分發任務並監督 Worker，讓 Worker 一直在執行任務; 如果 Leader " 發現某個 Worker 因意外狀況不能正常執行任務，則將該 Worker 從 Worker 隊列去除，並將其任務分給其他 Worker。基於容器技術的微服務架構 Kubernetes 就恰好採用了這一設計思路。

在分佈式中心化的設計思路中，還有一種設計思路與編程中敏捷開發的思路類似，即充分相信每個 Worker，Leader 只負責任務的生成而不再指派任務，由每個 Worker 自發領任務，從而避免讓個別 Worker 執行的任務過多，並鼓勵能者多勞。

中心化設計存在的最大問題是 Leader 的安全問題, 如果 Leader 出了問題, 則整個集羣崩潰。但我們難以同時安排兩個 Leader 以避免單點問題。爲了解決這個問題，大多數中心化系統都採用了主備兩個 Leader 的設計方案，可以是熱備或者冷備，也可以是自動切換或者手動切換，而且越來越多的新系統都具備了自動選舉切換 Leader 的能力，以提升系統的可用性。中心化設計還存在另外一個潛在的問題，即 Leader 的能力問題，如果系統設計和實現得不好，問題就會卡在 Leader 身上。

下面一起探討去中心化設計。

在去中心化設計裏通常不區分 Leader 和 Worker 這兩種角色。全球互聯網就是一個典型的去中心化的分佈式系統，聯網的任意節點設備宕機，都只會影響很小範圍的功能。去中心化設計的核心是在整個分佈式系統中不存在一個區別於其他節點的 Leader，因此不存在單點故障問題，但由於不存在 Leader，所以每個節點都需要與其他（所有）節點對話才能獲取必要的集羣信息，而分佈式系統通信的不可靠性大大增加了上述功能的實現難度。

去中心化設計中最難解決的一個問題是 “腦裂” 問題，這種情況的發生概率很低，但影響很大。腦裂指一個集羣由於網絡的故障，被分爲至少兩個彼此無法通信的單獨集羣，此時如果兩個集羣各自工作，則可能會產生嚴重的數據衝突和錯誤。一般的設計思路是，當集羣判斷髮生了腦裂問題時，規模較小的集羣就 “自殺” 或者拒絕服務。

實際上，完全意義的真正去中心化的分佈式系統並不多見。相反，在外部看來去中心化但工作機制採用了中心化設計思想的分佈式系統不斷出現。在這種架構下，集羣中的 Leader 是被動態選擇出來的，而不是人爲預先指定的，而且在集羣發生故障的情況下，集羣的成員會自發地舉行 “會議” 選舉新的 Leader 主持工作。最典型的案例就是 ZooKeeper 及用 Go 實現的 Etcd。

作者：大數據架構師
 來源：https://www.toutiao.com/a6920464611368124939/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TLFNvIUcsGuWAukbnxtBqg