什麼是分布式系統，如何學習分布式系統

什麼是分布式系統，如何學習分布式系統

目錄

• 什麼是分布式系統

• 分布式系統挑戰
• 分布式系統特性與衡量标準

• ​元件、理論、協定​

• ​​用一個請求串起來​​
• ​​一個簡化的架構圖​​
• ​​概念與實作​​

• ​​總結​​
• ​​references​​

正文

　　雖然本人在前面也寫過好幾篇分布式系統相關的文章，主要包括​​CAP理論​​、​​分布式存儲​​與​​分布式事務​​，但對于分布式系統，并沒有一個跟清晰的概念。分布式系統涉及到很多的技術、理論與協定，很多人也說，分布式系統是“入門容易，深入難”，我之前的學習也隻算是管中窺豹，隻見得其中一斑。是以，一緻希望能對分布式系統有一個更全面的認識，至少能夠把分布式系統中的各個技術、理論串起來，了解他們在分布式系統分别解決什麼問題，有哪些優秀的實作。

　　我曾在網絡上搜尋過”如何學習分布式系統“，也在知乎上關注了該話題，但并沒有看到一個全面的、有指導意義的答案。本文的目标是給打算全面學習分布式系統的自己、以及感興趣的讀者指明一條可行的路徑，使得之後的學習不再盲目。

　　不過，我并沒有越過這座山，我隻是站在山前，從前人留下的痕迹揣測山的全貌與溝壑，臆想的成分居多，還望各位大師指點迷津。

　　2018 03 14更新：對于如何學習分布式系統，經過思考，我覺得有更好的方法，請參見《​​分布式學習最佳實踐：從分布式系統的特征開始（附思維導圖）​​》​

​​回到頂部​​

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

　　首先需要明确的是，隻有當單個節點的處理能力無法滿足日益增長的計算、存儲任務的時候，且硬體的提升（加記憶體、加磁盤、使用更好的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、斷電，不确定磁盤什麼時候損壞，不确定每次網絡通信要延遲多久，也不确定通信對端是否處理了發送的消息。而分布式的規模放大了這個不确定性，不确定性是令人讨厭的，是以有諸多的分布式理論、協定來保證在這種不确定性的情況下，系統還能繼續正常工作。

　　而且，很多在實際系統中出現的問題，來源于設計時的盲目樂觀，覺得這個、那個應該不會出問題。​​Fallacies_of_distributed_computing​​很有意思，介紹了分布式系統新手可能的錯誤的假設：

The network is reliable.

Latency is zero.

Bandwidth is infinite.

The network is secure.

Topology doesn't change.

There is one administrator.

Transport cost is zero.

The network is homogeneous.

　　劉傑在《分布式系統原理介紹》中指出，處理這些異常的最佳原則是：在設計、推導、驗證分布式系統的協定、流程時,最重要的工作之一就是思考在執行流程的每個步驟時一旦發生各種異常的情況下系統的處理方式及造成的影響。

　　透明性：使用分布式系統的使用者并不關心系統是怎麼實作的，也不關心讀到的資料來自哪個節點，對使用者而言，分布式系統的最高境界是使用者根本感覺不到這是一個分布式系統，在《​​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）分發給關注這個主題的消費者。消息隊列起到了異步處理、應用解耦的作用。

　　上面提到，使用者操作會産生一些資料，這些資料忠實記錄了使用者的操作習慣、喜好，是各行各業最寶貴的财富。比如各種推薦、廣告投放、自動識别。這就催生了分布式計算平台，比如Hadoop，Storm等，用來處理這些海量的資料。

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

一個簡化的架構圖

　　下面用一個不大精确的架構圖，盡量還原分布式系統的組成部分（不過隻能展現出技術，不好展現出理論）

 　

概念與實作

　　那麼對于上面的各種技術與理論，業界有哪些實作呢，下面進行簡單羅列。

　　當然，下面的這些實作，小部分我用過，知其是以然；大部分聽說過，知其然；還有一部分之前聞所未聞，分類也不一定正确，隻是從其他文章抄過來的。羅列在這裡，以便日後或深或淺的學習。

• 負載均衡：

　　　　Nginx：高性能、高并發的web伺服器；功能包括負載均衡、反向代理、靜态内容緩存、通路控制；工作在應用層

　　　　LVS： Linux virtual server，基于叢集技術和Linux作業系統實作一個高性能、高可用的伺服器；工作在網絡層

• webserver：

　　　　Java：Tomcat，Apache，Jboss

　　　　Python：gunicorn、uwsgi、twisted、webpy、tornado

• service：　　

　　　　SOA、微服務、spring boot，django

• 容器：

　　　　docker，kubernetes

• cache：

　　　　memcache、redis等

• 協調中心：

　　　　zookeeper、etcd等

　　　　zookeeper使用了Paxos協定Paxos是強一緻性，高可用的去中心化分布式。zookeeper的使用場景非常廣泛，之後細講。

• rpc架構：

　　　　grpc、dubbo、brpc

　　　　dubbo是阿裡開源的Java語言開發的高性能RPC架構，在阿裡系的諸多架構中，都使用了dubbo + spring boot

• 消息隊列：

　　　　kafka、rabbitMQ、rocketMQ、QSP

　　　　消息隊列的應用場景：異步處理、應用解耦、流量削鋒和消息通訊

• 實時資料平台：

　　　　storm、akka

• 離線資料平台：

　　　　hadoop、spark

　　　　PS: apark、akka、kafka都是scala語言寫的，看到這個語言還是很牛逼的

• dbproxy：

　　　　cobar也是阿裡開源的，在阿裡系中使用也非常廣泛，是關系型資料庫的sharding + replica 代理

• db：

　　　　mysql、oracle、MongoDB、HBase

• 搜尋：

　　　　elasticsearch、solr

• 日志：

　　　　rsyslog、elk、flume

總結

　　寫這篇文章，我曾在網絡上搜尋過“如何學習分布式系統”，但實話說，沒有很認同的答案。也許，這确實是一個難以回答的問題。于是，我想自己寫出一個答案，但寫完這篇文章，感覺自己的回答也很混亂，也沒有說清楚，不過對我自己還是有一些指導意義的，比如，理清了分布式系統中會遇到的各種技術、理論、協定，以及通過一個例子展示他們是如何協作的，接下來就是各個擊破了。

　　網上的諸多回答，上來就是看各種論文，google三大件、paxos什麼的，個人覺得不是很實用。更好的過程，是先有一個整體的把握，然後自己思考會有什麼問題，帶着問題去尋求答案，在尋求答案的時候再去看論文。

　　另外，也有很多人提到，掌握好計算機基礎知識，如作業系統、計算機網絡，對學習分布式系統是大有裨益的，這一點我很贊同。分布式系統解決問題的思路是早就有的，很多都是前人研究透的問題，思想都是相同的。比如函數式程式設計中的map reduce之于Hadoop的MapReduce，比如磁盤存儲的raid之于Partition與Replication，比如IPC之于消息隊列。

references

回到頂部

Distributed systems for fun and profit  

劉傑：分布式原理介紹

Fallacies_of_distributed_computing

CMU 15-440: Distributed Systems Syllabus

Distributed Systems Principles and Paradigms

學習分布式系統需要怎樣的知識？