1. 程式人生 > >阿里P7總結分散式系統的經典基礎理論——中心化與去中心化

阿里P7總結分散式系統的經典基礎理論——中心化與去中心化

分散式系統從誕生髮展到現在已經走過十幾個年頭了,其中伴隨著一些很重要的基礎理論,正式這些影響深淵的基礎理論,奠定了分散式系統的見識基礎,造就了分散式領域的一座座巨集偉大廈。為了練就一身武功,讓我們從這些經典的分散式理論開始吧!

一、分散式系統的設計理念

分散式系統架構的第一原則是不要分佈!這句看似矛盾的話揭露了分散式系統的很多特徵。

首先,分散式系統的首要目標是提升系統的整體效能和吞吐量。如果最終設計出來的分散式系統佔用了10臺機器才勉強達到單機系統的兩倍效能,那麼這個分散式系統還有存在的價值嗎?另外,及時採用了分散式架構,也仍然需要盡力提升單機上的程式效能,是的整體效能達到最高。所以,我們忍讓需要掌握高薪更難單機程式的設計何程式設計技巧,例如多執行緒併發程式設計、多程序高效能IPC通訊、高效能的網路框架等。

其次,任何分散式系統都存在讓人無法迴避的風險和嚴重問題,即系統發聲故障的概率大大增加:小到一個伺服器的硬碟發聲故障或者宕機、一個網線唄老師啃壞,大到一個交換機甚至幾十臺伺服器一起歇火。在分散式系統下故障概率之所以增加,除了主要網路通訊天生的不可靠性及物理上的分佈部署,還猶豫X86伺服器的平直越來越差,遠不如UNIX小機器,這大概是工業化導致“工匠精神”的匱乏在IT上的一個縮印吧。

綜上分析,我們看到分散式系統設計的兩大關鍵目標是“效能”與“容錯性”,而這兩個目標的實現恰恰都是很棘手的問題,而且互相羈絆!舉例說明:比如我們要設計一個分散式儲存系統,處於對效能的考慮,寫檔案時先寫一個副本到某個機器上並立即返回,然後非同步發起多副本的複製過程,這種設計的效能最好,單存在“容錯性”的風險,既檔案寫完後,目標機器立即發生故障,導致檔案丟失!如果同時多謝個副本,每個副本成功以後再返回,則又導致“效能”下降,因為這個過程取決於最慢的那臺機器的效能。

由於“效能”的指標是絕對的,而容錯性的指標是相對的,而且實際上對於不同的資料與業務,我們要求的容錯性其實可以存在很大的差異:允許意外的丟失一些日之類的資料;允許一些資訊類的資料展示不一致二最終達到一致;而對交易類的資料則要求有很高的可靠性。於是你會發現,很多分散式系統的設計都提供了多種容錯性策略,以適應不同的業務場景,我們在學習何設計分散式系統的過程中也需要注意這一特性。

二、中心化的設計思想

中心化的設計思想很簡單,分散式叢集中的節點機器按照角色分工,大體上氛圍兩種角色:

“領導”和“幹活的”,“領導”通常負責分發任務並監督“幹活的”,發現誰太閒了,就想發設法地給其安排新任務,確保沒有一個“幹活的”能夠偷懶,如果“領導”發現某個“幹活的”因為勞累過度而病倒了,則是不會考慮先嚐試“醫治”他的,而是一腳踢出去,然後把他的任務分給其他人。其中微服務架構Kubernetes就恰好採用了這一設計思路。

中心化的設計存在的最大問題是“領導”的安危問題,如果“領導”出了問題,則群龍無首,整個叢集就奔潰了。但我們難以同時安排兩個“領導”以避免單點問題。為了解決這個問題,大多數中心化系統都採用了主備兩個“領導”的設計方案,可以是熱備或者冷備,也可以是自動切換或者手動切換,而且越來越多的新系統都開始具備自動選舉切換“領導”的能力,以提升系統的可用性。中心化設計還存在另外一個潛在的問題,既“領導”的能力問題:可以領導10個人高效工作並不意味著可以領導100個人高效工作,所以如果系統設計和實現得不好,問題就會卡在“領導”身上。

二、去中心化設計思想

在去中心化的設計裡,通常沒有“領導”和“幹活的”這兩種角色的區分,大家的角色都是一樣的,地位是平等的,全球網際網路就是一個典型的去中心化的分散式系統,聯網的任意節點裝置宕機,都只會影響很小範圍的功能。去中心化設計的核心在於整個分散式系統中不存在一個區別於其他節點的“領導”,因此不存在單點故障為題,但由於不存在“領導”‘所以每個節點都需要跟其他節點對話才能獲取到必要的叢集資訊,而分散式系統通訊的不可靠性,則大大增加了上述功能的實現難度。

去中心化設計裡最難解決的一個問題是“腦裂”問題,這種情況的發聲概率很低,但影響很大。腦裂問題,這種情況的發生概率很低,但影響很大。腦裂指一個叢集猶豫網路的故障,被分為至少兩個彼此無法通訊的單獨叢集,此時如果兩個叢集都各自工作,則可能會產生眼中的資料衝突何錯誤。一般的設計思路是,當叢集半段發聲了腦裂問題是,規模較小的叢集就“自殺”或者拒絕服務。

實際上,完全意義的真正去中心化的分散式系統並不多見。相反,外部開來去中心化單工作機制採用了中心化設計思想的分散式系統正在不斷湧出。在這種架構下,叢集中的領導是被動態選擇出來的,而不是認為預先置頂的,而且叢集發聲故障的情況下,叢集的成員會自發的舉行“會議”選舉新的“領導”主持工作。最典型的案例就是ZooKeeper及Go語言實現的Etcd

關於分散式系統架構的底層原理不是幾篇文章就能全部弄明白的,它的應用範圍覆蓋及廣,針對這些知識點我找了幾位架構師朋友錄製了視訊分享在我的群中:375989619都是分散式架構的底層實現原理。感興趣的朋友可以加進來看看,都是免費獲取的。