分散式緣何而起？從單兵，到游擊隊，到集團軍
- 2019 年 10 月 8 日
- 筆記
與其直接用些抽象、晦澀的技術名詞去給分散式下一個定義，還不如從理解分散式的發展驅動因素開始，我們一起去探尋它的本質，自然而然地也就清楚它的定義了。
在今天這篇文章中，我將帶你了解分散式的起源，是如何從單台電腦發展到分散式的，進而幫助你深入理解什麼是分散式。為了方便你更好地理解這個演進過程，我將不考慮多核、多處理器的情況，假定每台電腦都是單核、單處理器的。
分散式起源
單兵模式：單機模式
1946 年情人節發布的 ENIAC 是世界上的第一台通用電腦，它佔地 170 平米重達 30 噸，每秒可進行 5000 次加法或者 400 次乘法運算，標誌著單機模式的開始。
所謂單機模式是指，所有應用程式和數據均部署在一台電腦或伺服器上，由一台電腦完成所有的處理。
以鐵路售票系統為例，鐵路售票系統包括用戶管理、火車票管理和訂單管理等模組，數據包括用戶數據、火車票數據和訂單數據等，如果使用單機模式，那麼所有的模組和數據均會部署在同一台電腦上，也就是說數據存儲、請求處理均由該電腦完成。這種模式的好處是功能、程式碼和數據集中，便於維護、管理和執行。
單機模式的示意圖，如下所示：
這裡需要注意的是，本文的所有示意圖中，紫色虛線表示在一台電腦內。
事物均有兩面性，我們再來看看單機模式的缺點。單個電腦的處理能力取決於 CPU 和記憶體等，但硬體的發展速度和性能是有限的，而且升級硬體的性價比也是我們要考慮的，由此決定了 CPU 和記憶體等硬體的性能將成為單機模式的瓶頸。
你有沒有發現，單機模式和單兵作戰模式非常相似，單台電腦能力再強，就好比特種兵以一敵百，但終歸能力有限。此外，將所有任務都交給一台電腦，也會存在將所有雞蛋放到一個籃子里的風險，也就是單點失效問題。
歸納一下，單機模式的主要問題是：性能受限、存在單點失效問題。
游擊隊模式：數據並行或數據分散式
既然單機模式存在性能和可用性的問題。那麼，有沒有什麼更好的計算模式呢？答案是肯定的。
為解決單機模式的問題，並行計算得到了發展，進而出現了數據並行（也叫作數據分散式）模式。並行計算採用消息共享模式使用多台電腦並行運行或執行多項任務，核心原理是每台電腦上執行相同的程式，將數據進行拆分放到不同的電腦上進行計算。
請注意，並行計算強調的是對數據進行拆分，任務程式在每台機器上運行。要達到這個目的，我們必須首先把單機模式中的應用和數據分離，才可能實現對數據的拆分。這裡的應用就是執行任務的程式，任務就是提交的請求。以鐵路售票系統為例，運行在伺服器上的用戶管理、火車票管理和訂單管理等程式就是應用，用戶提交的查詢火車票、購買火車票的請求就是任務。
在單機模式中，應用和數據均在一台電腦或伺服器上，要實現數據的並行，首先必須將應用和數據分離以便將應用部署到不同的電腦或伺服器上；然後，對同類型的數據進行拆分，比方說，不同電腦或伺服器上的應用可以到不同的資料庫上獲取數據執行任務。
以鐵路售票系統的數據並行為例，主要包括兩個步驟，如下所示：
第一步，將應用與數據分離，分別部署到不同的伺服器上：
第二步，對數據進行拆分，比如把同一類型的數據拆分到兩個甚至更多的資料庫中，這樣應用伺服器上的任務就可以針對不同數據並行執行了。
對於鐵路售票系統來說，根據線路將用戶、火車票和訂單數據拆分到不同的資料庫中，部署到不同的伺服器上，比如京藏線的數據放在資料庫伺服器 1 上的資料庫中，滬深線的數據放在資料庫伺服器 2 上的資料庫中。
需要注意的是，為了更好地幫助你理解這個數據拆分的過程，我在這裡選擇拆分資料庫的方式進行講解。由於資料庫伺服器本身的並發特性，因此你也可以根據你的業務情況進行選擇，比方說所有業務伺服器共用一個資料庫伺服器，而不一定真的需要去進行資料庫拆分。
可以看出，在數據並行或數據分散式模式中，每台電腦都是全量地從頭到尾一條龍地執行一個程式，就像一個全能的鐵道游擊隊戰士。所以，你也可以將這種模式形象地理解成游擊隊模式，就和鐵道游擊隊插曲的歌詞有點類似：「我們扒飛車那個搞機槍，撞火車那個炸橋樑……」
這種模式的好處是，可以利用多台電腦並行處理多個請求，使得我們可以在相同的時間內完成更多的請求處理，解決了單機模式的計算效率瓶頸問題。但這種模式仍然存在如下幾個問題，在實際應用中，我們需要對其進行相應的優化：
- 相同的應用部署到不同的伺服器上，當大量用戶請求過來時，如何能比較均衡地轉發到不同的應用伺服器上呢？解決這個問題的方法是設計一個負載均衡器，我會在」分散式高可靠「模組與你講述負載均衡的相關原理。
- 當請求量較大時，對資料庫的頻繁讀寫操作，使得資料庫的 IO 訪問成為瓶頸。解決這個問題的方式是讀寫分離，讀資料庫只接收讀請求，寫資料庫只接收寫請求，當然讀寫資料庫之間要進行數據同步，以保證數據一致性。
- 當有些數據成為熱點數據時，會導致資料庫訪問頻繁，壓力增大。解決這個問題的方法是引入快取機制，將熱點數據載入到快取中，一方面可以減輕資料庫的壓力，另一方面也可以提升查詢效率。
從上面介紹可以看出，數據並行模式實現了多請求並行處理，但如果單個請求特別複雜，比方說需要幾天甚至一周時間的時候，數據並行模式的整體計算效率還是不夠高。
由此可見，數據並行模式的主要問題是：對提升單個任務的執行性能及降低時延無效。
集團軍模式：任務並行或任務分散式
那麼，有沒有辦法可以提高單個任務的執行性能，或者縮短單個任務的執行時間呢？答案是肯定的。任務並行（也叫作任務分散式）就是為解決這個問題而生的。那什麼是任務並行呢？
任務並行指的是，將單個複雜的任務拆分為多個子任務，從而使得多個子任務可以在不同的電腦上並行執行。
我們仍以鐵路售票系統為例，任務並行首先是對應用進行拆分，比如按照領域模型將用戶管理、火車票管理、訂單管理拆分成多個子系統分別運行在不同的電腦或伺服器上。換句話說，原本包括用戶管理、火車票管理和訂單管理的一個複雜任務，被拆分成了多個子任務在不同電腦或伺服器上執行，如下圖所示：
可以看出，任務並行模式完成一項複雜任務主要有兩個核心步驟：首先將單任務拆分成多個子任務，然後讓多個子任務並行執行。這種模式和集團軍模式很像，任務拆分者對應領導者，不同子系統對應不同兵種，不同子程式執行不同任務就像不同的兵種執行不同的命令一樣，並且運行相同子系統或子任務的電腦又可以組成一個兵團。
在集團軍模式中，由於多個子任務可以在多台電腦上運行，因此通過將同一任務待處理的數據分散到多個電腦上，在這些電腦上同時進行處理，就可以加快任務執行的速度。因為，只要一個複雜任務拆分出的任意子任務執行時間變短了，那麼這個任務的整體執行時間就變短了。
當然，nothing is perfect。集團軍模式在提供了更好的性能、擴展性、可維護性的同時，也帶來了設計上的複雜性問題，畢竟對一個大型業務的拆分也是一個難題。不過，對於大型業務來講，從長遠收益來看，這個短期的設計陣痛是值得的。這也是許多大型互聯網公司、高性能電腦構等競相對業務進行拆分以及重構的一個重要原因。
分散式是什麼？
講了半天，那到底什麼是分散式呢？
總結一下，分散式其實就是將相同或相關的程式運行在多台電腦上，從而實現特定目標的一種計算方式。
從這個定義來看，數據並行、任務並行其實都可以算作是分散式的一種形態。從這些計算方式的演變中不難看出，產生分散式的最主要驅動力量，是我們對於性能、可用性及可擴展性的不懈追求。
總結
在今天這篇文章中，我和你分享了分散式的起源，即從單機模式到數據並行（也叫作數據分散式）模式，再到任務並行（也叫作任務分散式）模式。
單機模式指的是，所有業務和數據均部署到同一台機器上。這種模式的好處是功能、程式碼和數據集中，便於維護、管理和執行，但計算效率是瓶頸。也就是說單機模式性能受限，也存在單點失效的問題。
數據並行（也叫作數據分散式）模式指的是，對數據進行拆分，利用多台電腦並行執行多個相同任務，通過在相同的時間內完成多個相同任務，從而縮短所有任務的總體執行時間，但對提升單個任務的執行性能及降低時延無效。
任務並行（也叫作任務分散式）模式指的是，單任務拆分成多個子任務，多個子任務並行執行，只要一個複雜任務中的任意子任務的執行時間變短了，那麼這個業務的整體執行時間也就變短了。該模式在提高性能、擴展性、可維護性等的同時，也帶來了設計上的複雜性問題，比如複雜任務的拆分。
在數據並行和任務並行這兩個模式的使用上，用戶通常會比較疑惑，到底是採用數據並行還是任務並行呢？
一個簡單的原則就是：任務執行時間短，數據規模大、類型相同且無依賴，則可採用數據並行；如果任務複雜、執行時間長，且任務可拆分為多個子任務，則考慮任務並行。在實際業務中，通常是這兩種模式並用。趕緊行動起來，去分析一下你的業務到底應該採用哪種分散式模式吧，加油！
最後你可以思考一下，你覺得分散式與傳統的並行計算的區別是什麼？你可以結合多核、多處理器的情況進行思考。
