一、什麼是分散式系統

　　分散式系統是由一組通過網路進行通訊、為了完成共同的任務而協調工作的計算機節點組成的系統。分散式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、儲存任務。其目的是利用更多的機器，處理更多的資料。

　　首先需要明確的是，只有當單個節點的處理能力無法滿足日益增長的計算、儲存任務的時候，且硬體的提升（加記憶體、加磁碟、使用更好的CPU）高昂到得不償失的時候，應用程式也不能進一步優化的時候，我們才需要考慮分散式系統。因為，分散式系統要解決的問題本身就是和單機系統一樣的，而由於分散式系統多節點、通過網路通訊的拓撲結構，會引入很多單機系統沒有的問題，為了解決這些問題又會引入更多的機制、協議，帶來更多的問題。。。

　　在很多文章中，主要講分散式系統分為分散式計算（computation）與分散式儲存（storage）。計算與儲存是相輔相成的，計算需要資料，要麼來自實時資料（流資料），要麼來自儲存的資料；而計算的結果也是需要儲存的。在作業系統中，對計算與儲存有非常詳盡的討論，分散式系統只不過將這些理論推廣到多個節點罷了。

　　那麼分散式系統怎麼將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那麼就是對計算任務進行切換，每個節點算一些，最終彙總就行了，這就是MapReduce的思想；對於儲存，更好理解一下，每個節點存一部分資料就行了。當資料規模變大的時候，Partition是唯一的選擇，同時也會帶來一些好處：
　　（1）提升效能和併發，操作被分發到不同的分片，相互獨立
　　（2）提升系統的可用性，即使部分分片不能用，其他分片不會受到影響

二、分片Partition與複製集Replication

　　理想的情況下，有分片就行了，但事實的情況卻不大理想。原因在於，分散式系統中有大量的節點，且通過網路通訊。單個節點的故障（程序crash、斷電、磁碟損壞）是個小概率事件，但整個系統的故障率會隨節點的增加而指數級增加，網路通訊也可能出現斷網、高延遲的情況。在這種一定會出現的“異常”情況下，分散式系統還是需要繼續穩定的對外提供服務，即需要較強的容錯性。最簡單的辦法，就是冗餘或者複製集（Replication），即多個節點負責同一個任務，最為常見的就是分散式儲存中，多個節點複雜儲存同一份資料，以此增強可用性與可靠性。同時，Replication也會帶來效能的提升，比如資料的locality可以減少使用者的等待時間。

　　下面這種來自Distributed systems for fun and profit 的圖形象生動說明了Partition與Replication是如何協作的。 
　　

　　Partition和Replication是解決分散式系統問題的一記組合拳，很多具體的問題都可以用這個思路去解決。但這並不是銀彈，往往是為了解決一個問題，會引入更多的問題，比如為了可用性與可靠性保證，引用了冗餘（複製集）。有了冗餘，各個副本間的一致性問題就變得很頭疼，一致性在系統的角度和使用者的角度又有不同的等級劃分。如果要保證強一致性，那麼會影響可用性與效能，在一些應用（比如電商、搜尋）是難以接受的。如果是最終一致性，那麼就需要處理資料衝突的情況。CAP、FLP這些理論告訴我們，在分散式系統中，沒有最佳的選擇，都是需要權衡，做出最合適的選擇。

三、分散式系統挑戰

分散式系統需要大量機器協作，面臨諸多的挑戰：
　　

第一，異構的機器與網路：

　　分散式系統中的機器，配置不一樣，其上執行的服務也可能由不同的語言、架構實現，因此處理能力也不一樣；節點間通過網路連線，而不同網路運營商提供的網路的頻寬、延時、丟包率又不一樣。怎麼保證大家齊頭並進，共同完成目標，這四個不小的挑戰。
　　

第二，普遍的節點故障：

　　雖然單個節點的故障概率較低，但節點數目達到一定規模，出故障的概率就變高了。分散式系統需要保證故障發生的時候，系統仍然是可用的，這就需要監控節點的狀態，在節點故障的情況下將該節點負責的計算、儲存任務轉移到其他節點
　　

第三，不可靠的網路：

　　節點間通過網路通訊，而網路是不可靠的。可能的網路問題包括：網路分割、延時、丟包、亂序。
　　相比單機過程呼叫，網路通訊最讓人頭疼的是超時：節點A向節點B發出請求，在約定的時間內沒有收到節點B的響應，那麼B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節點B會不會多次處理同一個請求。

總而言之，分散式的挑戰來自不確定性，不確定計算機什麼時候crash、斷電，不確定磁碟什麼時候損壞，不確定每次網路通訊要延遲多久，也不確定通訊對端是否處理了傳送的訊息。而分散式的規模放大了這個不確定性，不確定性是令人討厭的，所以有諸多的分散式理論、協議來保證在這種不確定性的情況下，系統還能繼續正常工作。

四、為什麼你要使用分散式？

分散式系統並非靈丹妙藥，解決問題的關鍵還是看你對問題本身的瞭解。通常我們需要使用分散式的常見理由是：

為了效能擴充套件——系統負載高，單臺機器無法承載，希望通過使用多臺機器來提高系統的負載能力

為了增強可靠性——軟體不是完美的，網路不是完美的，甚至機器本身也不可能是完美的，隨時可能會出錯，為了避免故障，需要將業務分散開保留一定的冗餘度。在以提供 Service 為主的服務端軟體開發過程中常常遇到這些問題。

五、一些分散式方案能解決你的問題，另一些卻不能，要學會的其實是選擇

籠統的討論分散式沒有太大的意義，就如我剛才所談的，實際上分散式很容易實現。真正難的地方在於如何選擇正確的分佈方案。

例如，當你想要建立一個分散式的資料管理系統的時候，你就必須得面對“一致性”問題。如果你對資料一致性要求很高，你就不得不容忍一些缺陷例如規模伸縮困難；而如果你放棄它，你可以輕鬆伸縮規模，但你必須解決好由此帶來的一系列資料不一致導致的問題。（CAP 問題）

於是你會意識到，有許多種分佈方案，為了正確解決你的問題，你需要對每一個方案都進行了解，並評估，選擇不同的方案有時候區別不大，有時候卻會深刻的影響整個系統中其他部分的工作方式，甚至影響使用者介面中使用者操作時的流程。這是我們學習分散式系統的重點所在。

六、分散式學習入門——基礎知識要點

如我前面所講，分散式入門不難。主要包含如下知識點：

Process（程序）。在分散式系統中，程序是基本單元。 
通訊協議。Process 間需要相互配合才能完成工作，因此通訊協議是最基本要解決的問題。這部分其實挺複雜，牽涉面光，不過核心還是抓住兩方面，一是存在哪些需求，二是各個協議如何滿足這些需求命名法。兩個 Process 要通訊，必須相互知道對方的名字，名字可以是數字，也可以是結構化的字串。例如眾所周知域名系統就是一種命名方案，但是方案還有很多，各有特點協作。

上面都在談 Process 之間的通訊，可是為什麼要通訊？因為要協作。協作是個複雜的主題，其中最基本最基本的一個問題就是同步問題。而聊同步問題必然要聊“鎖”……知識點就這麼展開了。

上面幾點是最基礎的知識。瞭解了這些其實就算入門了。可是如何進階呢？那麼必然要開始學習下面的問題：

一致性。資料儲存時，最基本的問題。其實也是實際設計系統時常常需要反覆考慮的問題
容錯。冗餘是容錯的基礎，但並不是全部，分散式本身為實現容錯提供了一些便利，這也是實際設計系統時常常需要考慮的問題

以上都是分散式系統的理論基礎，上海尚學堂Java學科在年前做了重大改進更新，加入了分散式系統課程，詳情可以點選 上海java培訓 檢視上海尚學堂Java課程大綱和詳情。獲取免費資料或者試聽資格可以聯絡客服諮詢。