分布式系統的經典理論

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

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

分布式系統的首要目標是提升系統的整體性能和吞吐量。如果最終設計出來的分布式系統占用了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。