點擊“藍字”關注我們吧

福利：有件小事想和大家說一下

菜菜哥，問你個問題，為什么現在的系統都設計為分布式系統呢？

這個問題問得好，就像為什么程序員會慢慢脫發一樣神奇

01

PART

分布式系統

身為二十一世紀的一名程序員，沒聽說過分布式系統就顯得自己好像沒有女票一樣尷尬。無論是出去面試跟面試官吹水，還是在工作中和同事吹水，分布式系統永遠是你顯得高人一等的籌碼。分布式系統已經誕生了好幾十年，說起來比我們八零后程序員好要老成，隨著現代互聯網的崛起，對于系統在性能，可靠性上的要求大大提高。

分布式系統的定義其實很簡單，也很抽象：任何由處于不同物理位置的多個進程提供相同服務的系統都可以稱之為分布式系統，退一萬步講，同一臺服務器上的不同進程也可以組成分布式系統

分布式系統的首要目標是提高系統的整體性能，但不僅限于吞吐量，可靠性，響應時間，數據一致性等，其中提高性能指標是最重要的。如果最終設計出來的分布式系統占用了更多的資源卻還比不上單機的性能，那這個分布式系統是失敗的，理論上沒有存在的價值

一個分布式系統的整體性能提高并不是單單依靠擴展來實現，提高單機的處理性能仍然很重要，一個把單機性能發揮到極致的分布式系統，在同等性能的需求下，采用的資源要遠遠小于其他系統。

02

PART

分布式系統痛點

一個好的分布式系統在性能方面要遠超單機系統，但是在數據行為方面要表現的和單機系統一樣優秀，其中包括數據的一致性，硬件的故障發生率，網絡的不穩定性等。

無論是單機系統還是分布式系統都存在無法回避并且無法徹底去除的風險，比如：硬盤發生故障，網絡發生癱瘓，光纖被挖.....分布式系統隨著節點的增加，把這些故障的發生率也隨之增大，所以分布式系統其中一個目標是要盡量降低這些風險，也就是所謂的容錯性。

既要快還要不出錯，這在“倫理”上是沖突的。就像我們平時說的分布式鎖，如果要保證對一個資源的修改不會發生線程安全問題，就要付出降低性能的代價。至于性能和容錯性怎樣選擇，還需要具體到每個業務場景中，比如支付場景中，數據的正確性可能要比性能指標更重要，而那些日志型數據，比如用戶的登錄日志，這些數據的最大特點就是允許小部分丟失，在這樣的日志系統設計中，可能性能指標要大于容錯性。

目前爛大街的CAP原則的講解，是針對分布式系統的一個抽象理論，包括之后BASE理論，也是針對分布式系統的一種指導方案。

分布式系統這么復雜，那設計一個分布式系統看來很難了？

什么叫很難？那叫非常難！！

03

PART

設計分布式系統

分布式系統的特性就決定了它自出生之日起，就有多個節點如何協同工作的難題。就像一個團隊，如果讓這個團隊有條不紊的工作本來就是個難題。一堆節點為了完成同樣的任務，注定需要一個規范方圓的規則。就目前已知的方案中，主要有中心化和去中心化兩種解決方案

中心化

中心化的分布式設計理念是目前主流的方案，在中心化的設計方案中，節點是有角色區分的：Leader節點和Work節點，即：領導和干活的。就和現實中類似，leader只負責分發任務和監督，Work節點只負責領取任務干活，多說一句，這里Work節點領取任務，當然從通信的角度來說，又可以分為push和pull（推和拉）方式。推方式是指，leader節點主動將任務分發給Work節點，拉方式是指：Work節點主動去申請任務。至于push和pull的優缺點，不作為今天的主題展開討論。

在任何系統中，都無可避免的需要考慮節點down掉的問題，分布式系統也一樣。在中心化分布式設計中，leader和Work也一樣都存在down掉的可能性。如果leader掉的話，整個系統都陷入癱瘓，按照最簡單的設計思路，leader節點需要一個從節點或者備用節點，在主節點down掉之后，從主節點或者備用主節點可以手動或者自動實現leader節點服務。至于一個Work節點down掉，一般不會使整個系統陷入癱瘓，除非全部Work節點同時down掉。一個Work節點down掉，但是會影響這個節點當前正在執行的任務，所以在必要的條件下可以設計成任務需要Ack才好，即：一個任務的完成需要確認，如果長時間沒有確認，leader會發起重新分配任務的操作。

說到leader的問題，現在目前大多數分布式系統都具備了自動選舉leader的功能，這還要感謝paxos，raft等選舉算法。在leader不可用的時候，這些系統會自動根據節點情況選舉出新的leader節點來繼續提供服務，這大大提高了系統可用性。

在所有的中心化設計中，數據的寫操作都發生在leader節點，這在某種程度上類似于單機系統，所以這種中心化設計并不適合那些大量寫的操作。

去中心化

在去中心化分布式系統設計中，節點類型并不區分Leader和Work，所有節點都是相等的。所以任何一個節點down掉都不會導致整個系統癱瘓，這是它的優勢。但是獲取系統中每個節點的信息卻比中心化設計要難很多，在中心化設計中，leader節點存儲著系統中所有的節點信息，并可以實時把這些信息同步到其他節點，同時可以利用相應算法來達到一致性的要求。去中心化的設計中，每個節點只能依靠和其他節點不斷通信來獲取整個系統的節點信息，這在技術難度上要比中心化高出很多。

在網絡中，網絡是不可靠的。恰恰是這個原因，又加大了每個節點互相通信的難度。在極限情況下，去中心化的設計方案會出現多個小范圍的“團伙”，這就是所說的腦裂。比如：現在一個由10個節點組成的分布式系統，有可能由于網絡原因會劃分為兩個5節點互相通信的兩個“團伙”

如果出現腦裂的情況，目前主流的解決方案和數據庫死鎖的處理情況類似，自爆一個對系統影響比較小的。

那我們設計分布式系統的時候是不是優先選擇中心化方案呢？

這個問題就像是選擇型數據庫，是選擇關系型還是非關系型一個道理，而目前多數的做法是采用揚長避短互相補充的方案

那就是混用哦？

可以這么說，分布式系統也一個道理

完全中心化和去中心化的系統并不常見，反而現在慢慢出現的是二者的搭配者，表面看似去中心化，設計理念卻是中心化的思路，在這種架構下，leader是程序根據某種算法選舉出來的，而且在系統leader發生故障的時候，系統會自動重新選舉leader節點。

04

PART

寫在最后

對于每個系統來說，可靠性是它要實現的主要目標之一，尤其是分布式系統。在網絡通信，硬件設備等條件都非100%可靠的情況下，如何提高分布式系統的可用性是一個很深的話題。就算是國內頂尖的BAT等大廠，也沒有一個系統能達到100%的可用性，4個9的可用性已經是很巔峰了。

分布式系統本質上是多個節點通過網絡IO組成的，其中夾雜著一些不可抗拒的元素，所以請記住一句話：

分布式系統是不可靠的，我們只能盡量減小故障發生率，卻根除不了，如果你的老板要你設計一套100%可用性的系統，要么他是二貨，要么他是二B

●程序員修神之路--為什么我會了SOA，你們還要逼我學微服務？

●程序員過關斬將--數據庫的樂觀鎖和悲觀鎖并非真實的鎖

●程序員修神之路--設計一套RPC框架并非易事

●程序員過關斬將--要想獲取我的用戶信息，就得按照規矩來

●程序員過關斬將--更加優雅的Token認證方式JWT

●程序員過關斬將--cookie和session的關系其實很簡單

●程序員修神之路--用NOSql給高并發系統加速

●程序員修神之路--高并發系統設計負載均衡架構

●程序員過關斬將--你為什么還在用存儲過程？

●程序員修神之路--問世間異步為何物？

●程序員修神之路--提高網站的吞吐

長按添加菜菜好友

關注后回復：“大禮包”和“福利”，領取驚喜

總結

以上是生活随笔為你收集整理的程序员修神之路--分布式系统设计理念这么难学？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。