1 前言
分佈式技術概念繁多、知識龐雜、新興技術層出不窮，令許多新手望而卻步。即使接觸了一段時間分佈式系統，仍然是經常各種概念、名詞張冠李戴，傻傻的分不清楚；甚至是做了多年技術，也參與了很多分佈式技術實踐，卻無法回答工作中各種分佈式技術、組件、框架選型背後的根源。究其原因，主要是知識碎片化、不成體系、見樹不見林。小編我就是這樣之前作爲傳統存儲工程師只瞭解產品層面的技術，目前轉型分佈式系統需要挑戰非常陡峭的學習曲線。所幸在極客時間學習了一門《分佈式技術原理與算法解析》的課程，終於對分佈式系統有了一個相對整體的認識。從今天開始我就按照章節把我的學習心得（筆記）分享給大家，希望對和我一樣的初學者有所啓迪。
2 分佈式“四縱四橫”知識體系
2.1 分佈式系統學習思路
學習分佈式技術關鍵要掌握分佈式的核心技術、體系，因爲很多新技術、新框架、新組件只不過是‘新瓶裝舊酒’，將分佈式核心技術進行了再包裝、再組合，至多也就是做了一點延伸而已。”按照**“四縱四橫”**的分佈式核心技術知識體系，從這個縱橫的技術體系中抽取最核心、最普適的技術思想以及概念，結合各種適用場景各個擊破，達到事半功倍的效果。
2.2 那麼何爲“四縱四橫”呢？
- 按照業務架構層次棧分出“四橫”：**首先自底向上按照資源、通信、數據與計算的維度，梳理出了 4 個技術層次：
- 分佈式資源池化
- 分佈式通信
- 分佈式數據存儲與管理
- 分佈式計算
- 把“四橫”比作派生類，則“四縱”就是其基類：**：在分佈式環境下，無論是資源、通信、數據還是計算，都需要去解決協同、調度、追蹤高可用，還有部署的問題。因此，從橫向的技術層次中，提煉出了4 個縱向技術線。
- 分佈式協同
- 分佈式調度
- 分佈式追蹤與高可用
- 分佈式部署
3 分佈式的起源和發展
3.1 單機模式
3.1.1 定義
所謂單機模式是指，所有應用程序和數據均部署在一臺電腦或服務器上，由一臺計算機完成所有的處理。
3.1.2 舉例說明
以鐵路售票系統爲例，業務系統包括：用戶管理、火車票管理和訂單管理等模塊，數據包括：用戶數據、火車票數據和訂單數據等，在單機模式中所有的模塊和數據均會部署在同一臺計算機上，也就是說數據存儲、請求處理均由該計算機完成。單機模式的示意圖，如下所示：
本文的所有示意圖中，紫色虛線表示在一臺計算機內
3.1.3 優缺點
優點 ：功能、代碼和數據集中，便於維護、管理和執行；
缺點 ：性能受限、存在單點失效問題；
3.2 數據並行或數據分佈式模式
3.2.1 定義
數據並行（也叫作數據分佈式）模式，採用消息共享模式使用多臺計算機並行運行或執行多項任務，核心原理是：每臺計算機上執行相同的程序，將數據進行拆分放到不同的計算機上進行計算。
並行計算強調的是對數據進行拆分，任務程序在每臺機器上運行。首先要把單機模式中的應用和數據分離，纔可能實現對數據的拆分。
這裏的應用就是執行任務的程序，任務就是提交的請求
3.2.2 舉例說明
以鐵路售票系統爲例，運行在服務器上的用戶管理、火車票管理和訂單管理等程序就是應用，用戶提交的查詢火車票、購買火車票的請求就是任務。
主要包括兩個步驟，如下所示：
**- 第一步，**將應用與數據分離，分別部署到不同的服務器上：
**- 第二步，**對數據進行拆分，比如把同一類型的數據拆分到兩個甚至更多的數據庫中，這樣應用服務器上的任務就可以針對不同數據並行執行了。
對於鐵路售票系統來說，根據線路將用戶、火車票和訂單數據拆分到不同的數據庫中，部署到不同的服務器上，比如京藏線的數據放在數據庫服務器 1 上的數據庫中，滬深線的數據放在數據庫服務器 2 上的數據庫中。
3.2.3 優缺點
優點： 多臺計算機並行處理多個請求，在相同時間內完成更多請求處理，解決了單機模式的計算效率瓶頸問題；
缺點： 如果單個請求特別複雜，數據並行模式的整體計算效率還是不夠高，即對提升單個任務的執行性能及降低時延無效；
3.3 任務並行或任務分佈式模式
3.3.1 定義
任務並行指的是，將單個複雜的任務拆分爲多個子任務，從而使得多個子任務可以在不同的計算機上並行執行
3.3.2 舉例說明
仍以鐵路售票系統爲例，任務並行首先是對應用進行拆分，比如按照領域模型將用戶管理、火車票管理、訂單管理拆分成多個子系統分別運行在不同的計算機或服務器上。換句話說，原本包括用戶管理、火車票管理和訂單管理的一個複雜任務，被拆分成了多個子任務在不同計算機或服務器上執行，如下圖所示：
任務並行模式完成一項複雜任務主要有兩個核心步驟：
- 首先將單任務拆分成多個子任務；
- 然後讓多個子任務並行執行；
3.3.3 優缺點
優點： 提供了更好的性能、擴展性、可維護性；
缺點： 系統設計複雜性問題；
3 什麼是分佈式系統
分佈式其實就是將相同或相關的程序運行在多臺計算機上，從而實現特定目標的一種計算方式。從這個定義來看，數據並行、任務並行其實都可以算作是分佈式的一種形態。
在數據並行和任務並行這兩個模式的使用上，一個簡單的原則就是：
- 任務執行時間短，數據規模大、類型相同且無依賴，則可採用數據並行；
- 如果任務複雜、執行時間長，且任務可拆分爲多個子任務，則考慮任務並行。
- 在實際業務中，通常是這兩種模式並用。
4 各場景下分佈式系統的指標要求
典型的電商、IoT、電信、HPC（高性能計算）、大數據、雲計算、區塊鏈等業務或系統對不同指標的訴求。
- 電商系統：對於一個電商系統而言，系統設計者最看重的是吞吐量，爲的是處理更多的用戶訪問或訂單業務。
- IoT：對於一個 IoT 系統而言，設計者最看重的是資源佔用指標，因爲在一些功能極簡的 IoT 設備上 RAM、ROM 的可用資源通常都是 KB級的。 - 電信業務：對於電信業務而言，最重要的無疑是響應時間、完成時間，以及可用性。
- HPC：系統最顯著的特點是任務執行時間極長，一個天體物理任務的分析和計算通常耗時數週甚至數月。因此，通過水平擴展來提高系統的加速比，是 HPC系統設計者需要關注的。
- 大數據：任務的處理時間可能相對 HPC系統來講比較短，但常見的完成時間也達到了小時級，所以擴展性也是大數據系統首先要考慮的。
- **雲計算：**對於一個雲計算系統而言，常見任務是虛擬主機或容器的創建、資源調整、銷燬等操作，如何減少這些操作的完成時間，從而提升用戶體驗是設計者們要重點關注的。另外，雲計算系統本質上賣的是資源，那麼降低系統本身的資源開銷，也是系統設計的重中之重。
- 區塊鏈：區塊鏈的吞吐量比較低，比特幣的TPS 只有 7 次每秒，單平均一次交易的確認就需要 10 分鐘左右，因此吞吐量和完成時間通常是區塊鏈系統設計者的首要目標。