一起進階學習JAVA：分布式理論（一）

• 什麼是分布式系統
• 分布式系統的特點
• 分布式系統的問題
• 分布式理論
• • 一緻性
  • • 副本一緻性
    • 一緻性分類
    • • 強一緻性
      • 弱一緻性
  • CAP定理
  • BASE 理論
  • 一緻性協定 2PC
  • • 2PC協定階段過程
    • 執行流程
    • 2PC協定的優缺點
    • • 優點
      • 缺點
  • 3PC協定
  • • 階段一：CanCommit
    • 階段二：PreCommit
    • 階段三：do Commit

什麼是分布式系統

分布式系統是一個硬體或軟體元件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。即将一個業務拆分成不同的幾個子業務并分别部署再不同的服務節點，共同構成的系統。

分布式系統的特點

• 分布性：不同的子業務分布在不同的服務節點
• 對等性：分布式系統中的各個節點都包含自己的處理機和記憶體,各自具有獨立的處理資料的功能
• 并發性：一個大的任務可以劃分為若幹個子任務,分别在不同的主機上執行
• 缺乏全局時鐘：因為分布性的原因，系統分布在不同的服務節點，而各個服務節點都有自己獨立的時鐘
• 故障

分布式系統的問題

1. 通信異常

   由于網絡本身的不可靠性導緻每次網絡通信都會伴随着不可用風險，最終會導緻不同服務節點的分布式系統無法進行網絡同學，并且網絡通信具有延時性，這也會影響到消息收發過程中的消息延遲或者丢失

2. 網絡分區

   網絡之間出現了網絡不連通，但是各個子網絡之間的内部網絡又是正常的，進而導緻整個系統的網絡環境被切分成了若幹個獨立的區域

3. 節點故障

   節點故障是分布式系統下比較常見的問題，節點故障指的是分布式系統的伺服器節點發生當機等現象

4. 三态

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

   分布式系統中，由于網絡是不可靠的，雖然絕大部分情況下，網絡通信能夠接收到成功或失敗的響應，但當網絡出現異常的情況下，就會出現逾時現象，通常有以下兩種情況：

   1）由于網絡原因，該請求并沒有被成功的發送到接收方，而是在發送過程就發生了丢失現象。

   2）該請求成功的被接收方接收後，并進行了處理，但在響應回報給發送方過程中，發生了消息丢失現象。

分布式理論

一緻性

分布式資料一緻性，指的是資料在多份副本中存儲時，各副本中的資料是一緻的。

副本一緻性

分布式系統當中，資料往往會有多個副本。如果是一台資料庫處理所有的資料請求，那麼通過ACID四原則，基本可以保證資料的一緻性。而多個副本就需要保證資料會有多份拷貝。這就帶來了同步的問題，因為我們幾乎沒有辦法保證可以同時更新所有機器當中的包括備份所有資料。 網絡延遲，即使我在同一時間給所有機器發送了更新資料的請求，也不能保證這些請求被響應的時間保持一緻存在時間差，就會存在某些機器之間的資料不一緻的情況。

一緻性分類

強一緻性

這種一緻性級别是最符合使用者直覺的，它要求系統寫入什麼，讀出來的也會是什麼，使用者體驗好，但實作起來往往對系統的性能影響大。但是強一緻性很難實作。

弱一緻性

這種一緻性級别限制了系統在寫入成功後，不承諾立即可以讀到寫入的值，也不承諾多久之後資料能夠達到一緻，但會盡可能地保證到某個時間級别（比如秒級别）後，資料能夠達到一緻狀态。

• 讀寫一緻性

  使用者讀取自己寫入結果的一緻性，保證使用者永遠能夠第一時間看到自己更新的内容。

  比如我們發一條朋友圈，朋友圈的内容是不是第一時間被朋友看見不重要，但是一定要顯示在自己的清單上.

  解決方案:
  方案1：一種方案是對于一些特定的内容我們每次都去主庫讀取。 （問題主庫壓力大）
  方案2：我們設定一個更新時間視窗，在剛剛更新的一段時間内，我們預設都從主庫讀取，過了這個視窗之後，我們會挑選最近有過更新的從庫進行讀取
  方案3：我們直接記錄使用者更新的時間戳，在請求的時候把這個時間戳帶上，凡是最後更新時間小于這個時間戳的從庫都不予以響應。
             

• 單調讀一緻性

  本次讀到的資料不能比上次讀到的舊。

  由于主從節點更新資料的時間不一緻，導緻使用者在不停地重新整理的時候，有時候能刷出來，再次重新整理之後會發現資料不見

  了，再重新整理又可能再刷出來，就好像遇見靈異事件一樣

  解決方案:
  就是根據使用者ID計算一個hash值，再通過hash值映射到機器。同一個使用者不管怎麼重新整理，都隻會被映射到同一台機器上。
  這樣就保證了不會讀到其他從庫的内容，帶來使用者體驗不好的影響。
             

• 因果一緻性

  如果節點 A 在更新完某個資料後通知了節點 B，那麼節點 B 之後對該資料的通路和修改都是基于 A 更新後的值。于此同時，和節點 A 無因果關系的節點 C 的資料通路則沒有這樣的限制。

• 最終一緻性

  最終一緻性是所有分布式一緻性模型當中最弱的。可以認為是沒有任何優化的“最”弱一緻性，它的意思是說，我不考慮所有的中間狀态的影響，隻保證當沒有新的更新之後，經過一段時間之後，最終系統内所有副本的資料是正确的。它最大程度上保證了系統的并發能力，也是以，在高并發的場景下，它也是使用最廣的一緻性模型。

  

CAP定理

CAP 理論含義是，一個分布式系統不可能同時滿足一緻性（C:Consistency)，可用性（A: Availability）和分區容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時滿足其中的2個。

選項	描述
C 一緻性	分布式系統當中的一緻性指的是所有節點的資料一緻，或者說是所有副本的資料一緻
A 可用性	Reads and writes always succeed. 也就是說系統一直可用，而且服務一直保持正常
P 分區容錯性	系統在遇到一些節點或者網絡分區故障的時候，仍然能夠提供滿足一緻性和可用性的服務

• C - Consistency

  一緻性是值寫操作後讀操作可以讀到最新的資料狀态,當資料分布在多個節點上時,從任意節點讀取到的資料都是最新的.

• A - Availability

  可用性是指任何操作都可以得到響應的結果,且不會出現響應逾時或響應錯誤。

• P - Partition tolerance

  分布式系統的各個節點部署在不同的子網中, 不可避免的會出現由于網絡問題導緻節點之間通信失敗,此時仍可以對外提供服務, 這個就是分區容錯性 (分區容忍性).

CAP隻能 3 選 2，假設有一個系統如下：

有使用者向N1發送了請求更改了資料，将資料庫從V0更新成了V1。由于網絡斷開，是以N2資料庫依然是V0，
如果這個時候有一個請求發給了N2，但是N2并沒有辦法可以直接給出最新的結果V1，這個時候該怎麼辦呢？

這個時候無法兩種方法，一種是将錯就錯，将錯誤的V0資料傳回給使用者。第二種是阻塞等待，等待網絡通信恢複，N2中
的資料更新之後再傳回給使用者。顯然前者犧牲了一緻性，後者犧牲了可用性。

這個例子雖然簡單，但是說明的内容卻很重要。在分布式系統當中，CAP三個特性我們是無法同時滿足的，必然要舍棄一
個。三者舍棄一個，顯然排列組合一共有三種可能。
           

1. 舍棄A(可用性)，保留CP(一緻性和分區容錯性)

   一個系統保證了一緻性和分區容錯性，舍棄可用性。也就是說在極端情況下，允許出現系統無法通路的情況出現，這個時候往往會犧牲使用者體驗，讓使用者保持等待，一直到系統資料一緻了之後，再恢複服務。

2. 舍棄C(一緻性)，保留AP(可用性和分區容錯性)

   這種是大部分的分布式系統的設計，保證高可用和分區容錯，但是會犧牲一緻性。

3. 舍棄P(分區容錯性)，保留CA(一緻性和可用性)

   如果要舍棄P，那麼就是要舍棄分布式系統，CAP也就無從談起了。可以說P是分布式系統的前提，是以這種情況是不存在的。

BASE 理論

BASE：全稱：Basically Available(基本可用)，Soft state（軟狀态）,和 Eventually consistent（最終一緻性）三個短語的縮寫，來自 ebay 的架構師提出。

BASE是對CAP中一緻性和可用性權衡的結果，BASE理論的核心思想是：即使無法做到強一緻性，但每個應用都可以根據自身業務特點，采用适當的方式來使系統達到最終一緻性。

• Basically Available(基本可用)

  基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價于系統不可用。

• Soft state（軟狀态）

  允許系統中的資料存在中間狀态，并認為該狀态不影響系統的整體可用性，即允許系統在多個不同節點的資料副本之間進行資料同步的過程中存在延遲。

• Eventually consistent（最終一緻性）

  最終一緻性強調的是系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一緻的狀态。是以最終一緻性的本質是需要系統保證最終資料能夠達到一緻，而不需要實時保證系統資料的強一緻性。

一緻性協定 2PC

2PC （ Two-Phase Commit縮寫）即兩階段送出協定，是将整個事務流程分為兩個階段，準備階段（Preparephase）、送出階段（commit phase），2是指兩個階段，P是指準備階段，C是指送出階段。

2PC協定階段過程

1. 準備階段（Prepare phase）：事務管理器給每個參與者發送Prepare消息，每個資料庫參與者在本地執行事務，并寫本地的Undo/Redo日志，此時事務沒有送出。 （Undo日志是記錄修改前的資料，用于資料庫復原，Redo日志是記錄修改後的資料，用于送出事務後寫入數 據檔案）
2. 送出階段（commit phase）：如果事務管理器收到了參與者的執行失敗或者逾時消息時，直接給每個參與者發送復原(Rollback)消息；否則，發送送出(Commit)消息；參與者根據事務管理器的指令執行送出或者復原操作，并釋放事務處理過程中使用的鎖資源。注意:必須在最後階段釋放鎖資源。

執行流程

• 成功執行事務事務送出流程

  

階段一:

1. 事務詢問協調者向所有的參與者發送事務内容，詢問是否可以執行事務送出操作，并開始等待各參與者的響應。
2. 執行事務 (寫本地的Undo/Redo日志)

3. 各參與者向協調者回報事務詢問的響應

   總結: 各個參與者進行投票是否讓事務進行.

階段二:

1. 發送送出請求：

   協調者向所有參與者發出 commit 請求。

2. 事務送出：

   參與者收到 commit 請求後，會正式執行事務送出操作，并在完成送出之後釋放整個事務執行期間占用的事務資源。

3. 回報事務送出結果：

   參與者在完成事務送出之後，向協調者發送 Ack 資訊。

4. 完成事務：

   協調者接收到所有參與者回報的 Ack 資訊後，完成事務。

   ACK 确認字元，在資料通信中，接收站發給發送站的一種傳輸類控制字元。表示發來的資料已确認接收無誤。

• 中斷事務步驟如下：

  假如任何一個參與者向協調者回報了No響應，或者在等待逾時之後，協調者尚無法接收到所有參與者的回報響應，那麼就會中斷事務

  

階段一:

1. 事務詢問

   協調者向所有的參與者發送事務内容，詢問是否可以執行事務送出操作，并開始等待各參與者的響應。

2. 執行事務 (寫本地的Undo/Redo日志)
3. 各參與者向協調者回報事務詢問的響應

總結: 各個參與者進行投票是否讓事務進行.

階段二:

1. 發送復原請求：

   協調者向所有參與者發出 Rollback 請求。

2. 事務復原：

   參與者接收到 Rollback 請求後，會利用其在階段一中記錄的 Undo 資訊來執行事務復原操作，并在完成復原之後釋放在整個事務執行期間占用的資源。

3. 回報事務復原結果：

   參與者在完成事務復原之後，向協調者發送 Ack 資訊。

4. 中斷事務：

   協調者接收到所有參與者回報的 Ack 資訊後，完成事務中斷。

從上面的邏輯可以看出，二階段送出就做了2個事情：投票，執行。

2PC協定的優缺點

優點

原理簡單，實作友善

缺點

• 同步阻塞：

  二階段送出協定存在最明顯也是最大的一個問題就是同步阻塞，在二階段送出的執行過程中，所有參與該事務操作的邏輯都處于阻塞狀态，也就是說，各個參與者在等待其他參與者響應的過程中，無法進行其他操作。這種同步阻塞極大的限制了分布式系統的性能。

• 單點問題：

  協調者在整個二階段送出過程中很重要，如果協調者在送出階段出現問題，那麼整個流程将無法運轉，更重要的是：其他參與者将會處于一直鎖定事務資源的狀态中，而無法繼續完成事務操作。

• 資料不一緻：

  假設當協調者向所有的參與者發送 commit 請求之後，發生了局部網絡異常或者是協調者在尚未發送完所有commit 請求之前自身發生了崩潰，導緻最終隻有部分參與者收到了 commit 請求。這将導緻嚴重的資料不一緻問題。

• 過于保守：

  如果在二階段送出的送出詢問階段中，參與者出現故障而導緻協調者始終無法擷取到所有參與者的響應資訊的話，這時協調者隻能依靠其自身的逾時機制來判斷是否需要中斷事務，顯然，這種政策過于保守。換句話說，二階段送出協定沒有設計較為完善的容錯機制，任意一個節點失敗都會導緻整個事務的失敗。

3PC協定

3PC，全稱 “three phase commit”，是 2PC 的改進版，将 2PC 的 “送出事務請求” 過程一分為二，共形成了由CanCommit、PreCommit和doCommit三個階段組成的事務處理協定。

階段一：CanCommit

1. 事務詢問

   協調者向所有的參與者發送一個包含事務内容的canCommit請求，詢問是否可以執行事務送出操作，并開始等待各參與者的響應。

2. 各參與者向協調者回報事務詢問的響應參與者在接收到來自協調者的包含了事務内容的canCommit請求後，正常情況下，如果自身認為可以順利執行事務，則回報Yes響應，并進入預備狀态，否則回報No響應。

階段二：PreCommit

協調者在得到所有參與者的響應之後，會根據結果有2種執行操作的情況：執行事務預送出，或者中斷事務假如所有參與回報的都是Yes，那麼就會執行事務預送出。

1. 發送預送出請求：

   協調者向所有參與者節點發出preCommit請求，并進入prepared階段。

2. 事務預送出：

   參與者接收到preCommit請求後，會執行事務操作，并将Undo和Redo資訊記錄到事務日志中。

3. 各參與者向協調者回報事務執行的結果：

   若參與者成功執行了事務操作，那麼回報Ack

若任一參與者回報了No響應，或者在等待逾時後，協調者尚無法接收到所有參與者回報，則中斷事務

1. 發送中斷請求：

   協調者向所有參與者發出abort請求。

2. 中斷事務：

   無論是收到來自協調者的abort請求或者等待協調者請求過程中逾時，參與者都會中斷事務

階段三：do Commit

該階段做真正的事務送出或者完成事務復原，是以就會出現兩種情況：

• 執行事務送出

1. 發送送出請求：

   進入這一階段，假設協調者處于正常工作狀态，并且它接收到了來自所有參與者的Ack響應，那麼他将從預送出狀态轉化為送出狀态，并向所有的參與者發送doCommit請求。

2. 事務送出：

   參與者接收到doCommit請求後，會正式執行事務送出操作，并在完成送出之後釋放整個事務執行過程中占用的事務資源。

3. 回報事務送出結果：

   參與者在完成事務送出後，向協調者發送Ack響應。

4. 完成事務：

   協調者接收到所有參與者回報的Ack消息後，完成事務。

• 中斷事務

1. 發送中斷請求：協調者向所有的參與者節點發送abort請求。
2. 事務復原：參與者收到abort請求後，會根據記錄的Undo資訊來執行事務復原，并在完成復原之後釋放整個事務執行期間占用的資源。
3. 回報事務復原結果：參與者在完成事務復原後，向協調者發送Ack消息。
4. 中斷事務：協調者接收到所有參與者回報的Ack消息後，中斷事務。

注意：一旦進入階段三，可能會出現 2 種故障：1. 協調者出現問題 2. 協調者和參與者之間的網絡故障

如果出現了任一一種情況，最終都會導緻參與者無法收到 doCommit 請求或者 abort 請求，針對這種情況，參與者都會在等待逾時之後，繼續進行事務送出

3PC協定并沒有完全解決資料不一緻問題。