分布式架構

什么是分布式系統

分布式系統是一個硬件或軟件組件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。

所謂分布式系統，就是一個業務拆分成多個子業務，分布在不同的服務器節點，共同構成的系統稱為分布式系統，同一個分布式系統中的服務器節點在空間部署上是可以隨意分布的，這些服務器可能放在不同的機柜中，也可能在不同的機房中，甚至分布在不同的城市。

分布式與集群的區別

集群: 多個服務器做同一個事情

分布式: 多個服務器做不同的事情

分布式系統特性

• 分布性：空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。
• 對等性：分布式系統中的計算機沒有主/從之分，組成分布式系統的所有節點都是對等的。
• 并發性：同一個分布式系統的多個節點，可能會并發地操作一些共享的資源，諸如數據庫或分布式存儲。
• 缺乏全局時鐘：既然各個計算機之間是依賴于交換信息來進行相互通信，很難定義兩件事件的先后順序，缺乏全局時鐘控制序列
• 故障總會發生：組成分布式的計算機，都有可能在某一時刻突然間崩掉。分的計算機越多，可能崩掉一個的幾率就
  越大。如果再考慮到設計程序時的異常故障，也會加大故障的概率。
• 處理單點故障：單點SPoF（Single Point of Failure）：某個角色或者功能只有某一臺計算機在支撐，在這臺計算機上出現的故障是單點故障。

分布式系統面臨的問題

• 通信異常
  網絡本身的不可靠性，因此每次網絡通信都會伴隨著網絡不可用的風險（光纖、路由、DNS等硬件設備或系統的不可用），都會導致最終分布式系統無法順利進行一次網絡通信，另外，即使分布式系統各節點之間的網絡通信能夠正常執行，其延時也會大于單機操作，存在巨大的延時差別，也會影響消息的收發過程，因此消息丟失和消息延遲變的非常普遍。
  

• 網絡分區
  網絡之間出現了網絡不連通，但各個子網絡的內部網絡是正常的，從而導致整個系統的網絡環境被切分成了若干個孤立的區域，分布式系統就會出現局部小集群，在極端情況下，這些小集群會獨立完成原本需要整個分布式系統才能完成的功能，包括數據的事務處理，這就對分布式一致性提出非常大的挑戰。
  

• 節點故障
  節點故障是分布式系統下另一個比較常見的問題，指的是組成分布式系統的服務器節點出現的宕機或"僵死"現象，根據經驗來說，每個節點都有可能出現故障，并且經常發生.

• 三態
  分布式系統每一次請求與響應存在特有的“三態”概念，即成功、失敗和超時。
  

• 重發
  分布式系統在發生調用的時候可能會出現 失敗 超時 的情況. 這個時候需要重新發起調用.
  

• 冪等
  一次和多次請求某一個資源對于資源本身應該具有同樣的結果（網絡超時等問題除外）。也就是說，其任意多次執行對資源本身所產生的影響均與一次執行的影響相同
  

分布式理論

數據一致性

分布式數據一致性，指的是數據在多份副本中存儲時，各副本中的數據是一致的。

副本一致性
分布式系統當中，數據往往會有多個副本。多個副本就需要保證數據的一致性。這就帶來了同步的問題，因為網絡延遲等因素, 我們幾乎沒有辦法保證可以同時更新所有機器當中的包括備份所有數據. 就會有數據不一致的情況。

一致性分類

1. 強一致性：是最符合用戶直覺的，它要求系統寫入什么，讀出來的也會是什么，用戶體驗好，但實現起來往往對系統的性能影響大。強一致性很難實現。

2. 弱一致性：約束了系統在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數據能夠達到一致狀態。

3. 最終一致性：最終一致性也是弱一致性的一種，它無法保證數據更新后，所有后續的訪問都能看到最新數值，而是需要一個時間，在這個時間之后可以保證這一點（就是在一段時間后，節點間的數據會最終達到一致狀態），而在這個時間內，數據也許是不一致的，這個系統無法保證強一致性的時間片段被稱為「不一致窗口」。不一致窗口的時間長短取決于很多因素，比如備份數據的個數、網絡傳輸延遲速度、系統負載等。
   
   最終一致性在實際應用中又有多種變種：

   • 因果一致性：如果進程A通知進程B它已更新了一個數據項，那么進程B的后續訪問將返回更新后的值。與進程A無因果關系的進程C的訪問遵守一般的最終一致性規則
     
   • 讀己之所寫一致性：當進程A自己更新一個數據項之后，它總是訪問到更新過的值，絕不會看到舊值。這是因果一致性模型的一個特例
     
   • 會話一致性：它把訪問存儲系統的進程放到會話的上下文中。只要會話還存在，系統就保證“讀己之所寫”一致性。如果由于某些失敗情形令會話終止，就要建立新的會話，而且系統的保證不會延續到新的會話。
     
   • 單調讀一致性：如果一個進程已經讀取到一個特定值，那么該進程不會讀取到該值以前的任何值。
     
   • 單調寫一致性：系統保證對同一個進程的寫操作串行化。
     

4. 一致性模型圖
   

CAP理論

CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer’s theorem），它指出對于一個分布式計算系統來說，不可能同時滿足以下三點

選項	含義
一致性（Consistency）	所有節點訪問時都是同一份最新的數據副本
可用性（Availability）	每次請求都能獲取到正常的響應，但是不保證獲取的數據為最新數據
分區容錯性（Partition tolerance）	分布式系統在遇到任何網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務， 除非整個網絡環境都發生了故障

1. 一致性
   這里指的是強一致性
   在寫操作完成后開始的任何讀操作都必須返回該值，或者后續寫操作的結果. 也就是說，在一致性系統中，一旦客戶端將值寫入任何一臺服務器并獲得響應，那么之后client從其他任何服務器讀取的都是剛寫入的數據
   

   • 客戶端向G1寫入數據v1，并等待響應
   • 此時，G1服務器的數據為v1，而G2服務器的數據為v0，兩者不一致
   • 接著，在返回響應給客戶端之前，G2服務器會自動同步G1服務器的數據，使得G2服務器的數據也是v1
   • 一致性保證了不管向哪臺服務器（比如這邊向G1）寫入數據，其他的服務器（G2）能實時同步數據
   • G2已經同步了G1的數據，會告訴G1，我已經同步了
   • G1接收了所有同步服務器的已同步的報告，才將“寫入成功”信息響應給client
   • client再發起請求，讀取G2的數據
   • 此時得到的響應是v1，即使client讀取數據到G2

2. 可用性
   系統中非故障節點收到的每個請求都必須有響應. 在可用系統中，如果我們的客戶端向服務器發送請求，并且服務器未崩潰，則服務器必須最終響應客戶端，不允許服務器忽略客戶的請求

3. 分區容錯性
   允許網絡丟失從一個節點發送到另一個節點的任意多條消息，即不同步. 也就是說，G1和G2發送給對方的任何消息都是可以放棄的，也就是說G1和G2可能因為各種意外情況，導致無法成功進行同步，分布式系統要能容忍這種情況。
   
   在實際的業務中，這三方面是不能同時滿足的，也很容易證明，最多只能滿足其中的兩個
   

CAP三者如何權衡

• CA (Consistency + Availability)：關注一致性和可用性，它需要非常嚴格的全體一致的協議。CA 系統不能容忍網絡錯誤或節點錯誤，一旦出現這樣的問題，整個系統就會拒絕寫請求，因為它并不知道對面的那個結點是否掛掉了，還是只是網絡問題。唯一安全的做法就是把自己變成只讀的。
• CP (consistency + partition tolerance)：關注一致性和分區容忍性。它關注的是系統里大多數人的一致性協議。這樣的系統只需要保證大多數結點數據一致，而少數的結點會在沒有同步到最新版本的數據時變成不可用的狀態。這樣能夠提供一部分的可用性。
• AP (availability + partition tolerance)：這樣的系統關心可用性和分區容忍性。因此，這樣的系統不能達成一致性，需要給出數據沖突，給出數據沖突就需要維護數據版本。

如何進行3選2：
放棄了一致性，滿足分區容錯，那么節點之間就有可能失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會容易導致全局數據不一致性。對于互聯網應用來說，機器數量龐大，節點分散，網絡故障再正常不過了，那么此時就是保障AP，放棄C的場景，而從實際中理解，像網站這種偶爾沒有一致性是能接受的，但不能訪問問題就非常大了。
對于銀行來說，就是必須保證強一致性，也就是說C必須存在，那么就只用CA和CP兩種情況，當保障強一致性和可用性（CA），那么一旦出現通信故障，系統將完全不可用。另一方面，如果保障了強一致性和分區容錯（CP），那么就具備了部分可用性。實際究竟應該選擇什么，是需要通過業務場景進行權衡的（并不是所有情況都是CP好于CA，只能查看信息但不能更新信息有時候還不如直接拒絕服務）

BASE理論

上面我們講到CAP 不可能同時滿足，而分區容錯性是對于分布式系統而言，是必須的。最后，我們說，如果系統能夠同時實現 CAP 是再好不過的了，所以出現了 BASE 理論

BASE：全稱：Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫 ,Base 理論是對 CAP 中一致性和可用性權衡的結果，其來源于對大型互聯網分布式實踐的總結，是基于 CAP 定理逐步演化而來的。其核心思想是： 既是無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。

1. Basically Available(基本可用)
   什么是基本可用呢？假設系統，出現了不可預知的故障，但還是能用，相比較正常的系統而言：

   • 響應時間上的損失：正常情況下的搜索引擎 0.5 秒即返回給用戶結果，而基本可用的搜索引擎可以在 1 秒返回結果。
   • 功能上的損失：在一個電商網站上，正常情況下，用戶可以順利完成每一筆訂單，但是到了大促期間，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面
     

2. Soft state（軟狀態）
   什么是軟狀態呢？相對于原子性而言，要求多個節點的數據副本都是一致的，這是一種 “硬狀態”。軟狀態指的是：允許系統中的數據存在中間狀態，并認為該狀態不會影響系統的整體可用性，即允許系統在多個不同節點的數據副本存在數據延時

3. Eventually consistent（最終一致性）
   上面說軟狀態，然后不可能一直是軟狀態，必須有個時間期限。在期限過后，應當保證所有副本保持數據一致性。從而達到數據的最終一致性。這個時間期限取決于網絡延時，系統負載，數據復制方案設計等等因素。