什麼是分佈式系統

分佈式系統是由一組通過網絡進行通信、為了完成共同的任務而協調工作的計算機節點組成的系統。分佈式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、存儲任務。其目的是

利用更多的機器，處理更多的數據。

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

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

那麼分佈式系統怎麼將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那麼就是對計算任務進行切換，每個節點算一些，最終彙總就行了，這就是MapReduce的思想；對於存儲，更好理解一下，每個節點存一部分數據就行了。當數據規模變大的時候，Partition是唯一的選擇，同時也會帶來一些好處：

（1）提升性能和併發，操作被分發到不同的分片，相互獨立

（2）提升系統的可用性，即使部分分片不能用，其他分片不會受到影響

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

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

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

分佈式系統挑戰

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

第一，異構的機器與網絡

第二，普遍的節點故障

第三，不可靠的網絡

節點間通過網絡通信，而網絡是不可靠的。可能的網絡問題包括：網絡分割、延時、丟包、亂序。

相比單機過程調用，網絡通信最讓人頭疼的是超時：節點A向節點B發出請求，在約定的時間內沒有收到節點B的響應，那麼B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節點B會不會多次處理同一個請求。

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

分佈式系統特性與衡量標準

透明性：使用分佈式系統的用戶並不關心繫統是怎麼實現的，也不關心讀到的數據來自哪個節點，對用戶而言，分佈式系統的最高境界是用戶根本感知不到這是一個分佈式系統，在《Distributed Systems Principles and Paradigms》一書中，作者是這麼說的：

A distributed system is a collection of independent computers that appears to its users as a single coherent system.　　

可擴展性：分佈式系統的根本目標就是為了處理單個計算機無法處理的任務，當任務增加的時候，分佈式系統的處理能力需要隨之增加。簡單來說，要比較方便的通過增加機器來應對數據量的增長，同時，當任務規模縮減的時候，可以撤掉一些多餘的機器，達到動態伸縮的效果

可用性與可靠性：一般來說，分佈式系統是需要長時間甚至7*24小時提供服務的。可用性是指系統在各種情況對外提供服務的能力，簡單來說，可以通過不可用時間與正常服務時間的必知來衡量；而可靠性而是指計算結果正確、存儲的數據不丟失。

高性能：不管是單機還是分佈式系統，大家都非常關注性能。不同的系統對性能的衡量指標是不同的，最常見的：高併發，單位時間內處理的任務越多越好；低延遲：每個任務的平均時間越少越好。這個其實跟操作系統CPU的調度策略很像

一致性：分佈式系統為了提高可用性可靠性，一般會引入冗餘（複製集）。那麼如何保證這些節點上的狀態一致，這就是分佈式系統不得不面對的一致性問題。一致性有很多等級，一致性越強，對用戶越友好，但會制約系統的可用性；一致性等級越低，用戶就需要兼容數據不一致的情況，但系統的可用性、併發性很高很多。

組件、理論、協議

假設這是一個對外提供服務的大型分佈式系統，用戶連接到系統，做一些操作，產生一些需要存儲的數據，那麼在這個過程中，會遇到哪些組件、理論與協議呢

用一個請求串起來

用戶使用Web、APP、SDK，通過HTTP、TCP連接到系統。在分佈式系統中，為了高併發、高可用，一般都是多個節點提供相同的服務。那麼，第一個問題就是具體選擇哪個節點來提供服務，這個就是負載均衡（load balance）。負載均衡的思想很簡單，但使用非常廣泛，在分佈式系統、大型網站的方方面面都有使用，或者說，只要涉及到多個節點提供同質的服務，就需要負載均衡。

通過負載均衡找到一個節點，接下來就是真正處理用戶的請求，請求有可能簡單，也有可能很複雜。簡單的請求，比如讀取數據，那麼很可能是有緩存的，即分佈式緩存，如果緩存沒有命中，那麼需要去數據庫拉取數據。對於複雜的請求，可能會調用到系統中其他的服務。

承上，假設服務A需要調用服務B的服務，首先兩個節點需要通信，網絡通信都是建立在TCP/IP協議的基礎上，但是，每個應用都手寫socket是一件冗雜、低效的事情，因此需要應用層的封裝，因此有了HTTP、FTP等各種應用層協議。當系統愈加複雜，提供大量的http接口也是一件困難的事情。因此，有了更進一步的抽象，那就是RPC（remote produce call），是的遠程調用就跟本地過程調用一樣方便，屏蔽了網絡通信等諸多細節，增加新的接口也更加方便。

一個請求可能包含諸多操作，即在服務A上做一些操作，然後在服務B上做另一些操作。比如簡化版的網絡購物，在訂單服務上發貨，在賬戶服務上扣款。這兩個操作需要保證原子性，要麼都成功，要麼都不操作。這就涉及到分佈式事務的問題，分佈式事務是從應用層面保證一致性：某種守恆關係。

上面說道一個請求包含多個操作，其實就是涉及到多個服務，分佈式系統中有大量的服務，每個服務又是多個節點組成。那麼一個服務怎麼找到另一個服務（的某個節點呢）？通信是需要地址的，怎麼獲取這個地址，最簡單的辦法就是配置文件寫死，或者寫入到數據庫，但這些方法在節點數據巨大、節點動態增刪的時候都不大方便，這個時候就需要服務註冊與發現：提供服務的節點向一個協調中心註冊自己的地址，使用服務的節點去協調中心拉取地址。

從上可以看見，協調中心提供了中心化的服務：以一組節點提供類似單點的服務，使用非常廣泛，比如命令服務、分佈式鎖。協調中心最出名的就是chubby，zookeeper。

回到用戶請求這個點，請求操作會產生一些數據、日誌，通常為信息，其他一些系統可能會對這些消息感興趣，比如個性化推薦、監控等，這裡就抽象出了兩個概念，消息的生產者與消費者。那麼生產者怎麼講消息發送給消費者呢，RPC並不是一個很好的選擇，因為RPC肯定得指定消息發給誰，但實際的情況是生產者並不清楚、也不關心誰會消費這個消息，這個時候消息隊列就出馬了。簡單來說，生產者只用往消息隊列裡面發就行了，隊列會將消息按主題（topic）分發給關注這個主題的消費者。消息隊列起到了異步處理、應用解耦的作用。

這裡的視頻是每天不斷更新的，每天都有新的視頻每天都有大牛講解新的技術，如果想學習Java工程化、高性能及分佈式、深入淺出。性能調優、Spring，MyBatis，Netty源碼分析的朋友可以加Java進階群：582505643，群裡有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

上面提到，用戶操作會產生一些數據，這些數據忠實記錄了用戶的操作習慣、喜好，是各行各業最寶貴的財富。比如各種推薦、廣告投放、自動識別。這就催生了分佈式計算平臺，比如Hadoop，Storm等，用來處理這些海量的數據。

最後，用戶的操作完成之後，用戶的數據需要持久化，但數據量很大，大到按個節點無法存儲，那麼這個時候就需要分佈式存儲：將數據進行劃分放在不同的節點上，同時，為了防止數據的丟失，每一份數據會保存多分。傳統的關係型數據庫是單點存儲，為了在應用層透明的情況下分庫分表，會引用額外的代理層。而對於NoSql，一般天然支持分佈式。

一個簡化的架構圖

下面用一個不大精確的架構圖，儘量還原分佈式系統的組成部分（不過只能體現出技術，不好體現出理論）