一文讀懂分佈式事務及其解決方案

一、什麼是事務？

   事務提供一種機制將活動中涉及所有操作納入到一個不可分割的執行單元。整個單獨單元作爲一個不可分割的整體，如果單元中某條sql語句一旦執行失敗或者產生錯誤，整個單元將會回滾，也就是所有受到影響的數據將會返回到事務開始以前的狀態；如果單元中的所有sql語句均執行成功，則事務被順利執行。

事務的屬性

• 原子性：一個事務不可在分割，要麼都執行要麼都不執行；
• 一致性：一個事務的執行會使數據從一個一致狀態切換到另一個一致的狀態；
• 隔離性：一個事務的執行不受其他事物的干擾；
• 持久性： 一個事務一旦提交，則會永久的改變數據庫的數據；

二、什麼是分佈式事務？

在系統當中，包含了庫存和訂單兩個獨立的服務，每個服務維護了自己的數據庫。
在發生交易時，我們購買商品，先調用庫存服務，減庫存，再調用訂單服務，創建訂單。
正常情況下，兩個數據庫都更新成功，兩邊數據維持着一致性。
但是，也會出現非正常情況，如減庫存完成後，創建訂單失敗，這時導致兩邊數據不一致。

在不同的服務怎麼保證大家都成功呢？ 分佈式事務。
   分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。

三、分佈式系統的一致性

1、CAP原則

   CAP原則又稱CAP定理，指的是在一個分佈式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。

• 一致性（C）：在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
• 可用性（A）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
• 分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。

  CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。

2、Base理論

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

四、分佈式事務的解決方案

1、2PC

  二階段提交(Two-phaseCommit)，強一致性解決方案；
  兩個階段：準備階段和提交階段。

  準備階段
  協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”消息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”消息。

  提交階段
  如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)。

方案總結：
  2PC 方案實現起來非常簡單，但是會帶來以下問題：

• 性能問題：在提交階段所有事務參與者處於同步阻塞狀態，容易導致性能瓶頸
• 可靠性：單點故障問題，一旦協調者宕機了，所有事務參與者將阻塞。
• 數據一致性：部分事務參與者收到了commit消息，另一部分參與者沒有收到commit消息，那麼導致節點之間的數據不一致問題。

2、3PC

  三階段提交協議，是二階段提交協議的改進版本，與二階段提交不同的是，引入超時機制。同時在協調者和參與者中都引入超時機制。
  三階段提交將二階段的準備階段拆分爲2個階段，插入了一個preCommit階段，使得原先在二階段提交中，參與者在準備之後，由於協調者發生崩潰或錯誤，而導致參與者處於無法知曉是否提交或者中止的“不確定狀態”所產生的可能相當長的延時的問題得以解決。
  三個階段：CanCommit階段、PreCommit階段、doCommit階段。

CanCommit階段
  協調者向參與者發送commit請求，參與者如果可以提交就返回yes響應(參與者不執行事務操作)，否則返回no響應。

PreCommit階段
  協調者根據階段1 canCommit參與者的反應情況來決定是否可以基於事務的preCommit操作。如果CanCommit階段所有參與者均反饋yes，所有參與者預執行事務；如果CanCommit階段任何一個參與者反饋no，或者等待超時後協調者尚無法收到所有參與者的反饋，即中斷事務。

doCommit階段
  該階段進行真正的事務提交。PreCommit階段所有參與者均反饋ack響應，執行真正的事務提交。如果任何一個參與者反饋no，或者等待超時後協調者尚無法收到所有參與者的反饋，即中斷事務。

方案總結：

• 優點：相比二階段提交，三階段貼近降低了阻塞範圍，PreCommit階段在等待超時後協調者或參與者會中斷事務。避免了協調者單點問題，doCommit階段中協調者出現問題時，參與者會繼續提交事務。

• 缺點：數據不一致問題依然存在，當在參與者收到preCommit請求後等待do commite指令時，此時如果協調者請求中斷事務，而協調者無法與參與者正常通信，會導致參與者繼續提交事務，造成數據不一致。

3、TCC

  TCC是服務化的二階段編程模型，最終一致性，其Try、Confirm、Cancel 3個方法均由業務編碼實現；

• Try操作作爲一階段，負責資源的檢查和預留。
• Confirm操作作爲二階段提交操作，執行真正的業務。
• Cancel是預留資源的取消。

TCC事務的Try、Confirm、Cancel可以理解爲SQL事務中的Lock、Commit、Rollback。

Try 階段
  這個階段主要完成所有業務檢查( 一致性 )、預留必須業務資源( 準隔離性 )；
  Try 嘗試執行業務 TCC事務機制以初步操作（Try）爲中心的，確認操作（Confirm）和取消操作（Cancel）都是圍繞初步操作（Try）而展開。因此，Try階段中的操作，其保障性是最好的，即使失敗，仍然有取消操作（Cancel）可以將其執行結果撤銷。

Confirm / Cancel 階段
  根據Try階段服務是否全部正常執行，繼續執行確認操作（Confirm）或取消操作（Cancel）。 Confirm和Cancel操作滿足冪等性，如果Confirm或Cancel操作執行失敗，將會不斷重試直到執行完成。（重試機制+冪等特性）

方案總結：
  TCC事務機制相對於傳統事務機制（X/Open XA），TCC事務機制相比於上面介紹的XA事務機制，有以下優點:

• 性能提升：具體業務來實現控制資源鎖的粒度變小，不會鎖定整個資源。
• 數據最終一致性：基於Confirm和Cancel的冪等性，保證事務最終完成確認或者取消，保證數據的一致性。
• 可靠性：解決了XA協議的協調者單點故障問題，由主業務方發起並控制整個業務活動，業務活動管理器也變成多點，引入集羣。

缺點： TCC的Try、Confirm和Cancel操作功能要按具體業務來實現，業務耦合度較高，提高了開發成本。

4、本地消息表

  本地消息表的方案最初是由ebay提出，此方案的核心是將需要分佈式處理的任務通過消息日誌的方式來異步執行。消息日誌可以存儲到本地文本、數據庫或消息隊列，再通過業務規則自動或人工發起重試。人工重試更多的是應用於支付場景，通過對賬系統對事後問題的處理。

5、Saga

  Saga事務 ，最終一致性，核心思想是將一個長事務拆分爲多個本地短事務來處理。

• 每一個Saga事務都是由一系列的冪等有序的子事務(sub-transaction) Ti組成。
• 每一個Ti都有對應一個冪等補償動作Ci，補償動作作用於撤銷Ti執行的結果。

Saga二種恢復策略：

• 向前恢復 （適用於必須要成功的場景）：如果在執行過程中發現子事務出現錯誤，會一直重試知道成功爲止，纔會進行下一個事務執行。
• 向後恢復（每一個操作都對應一個補償操作）：把前面執行成功事務進行撤銷。
  

Saga事務常見的實現方式：

• 命令協調: 中央協調器負責集中處理事件的決策和業務邏輯進行排序。
• 事件編排: 沒有協調器，也不會出現單點問題，每個服務產生並觀察其他服務的世界，並決定是否執行自己的邏輯。

方案總結：

命令協調優點和缺點

• 優點：服務之間關係簡單，避免服務之間的依賴關係；程序開發簡單，降低了參與者的複雜性；易於維護擴展
• 缺點：協調器中的邏輯如果比較複雜，導致後期維護困難；存在單點故障問題。

事件編排的優點和缺點

• 優點：不存在中央協調器，避免了單點故障問題；當涉及的步驟較少服務開發簡單，容易實現。
• 缺點：服務之間存在循環依賴的問題；服務步驟涉及比較多情況下，服務之間關係混亂，不易於調試。

五、總結

  本文介紹了分佈式事務的一些特性和解決方案，結合自己的項目實際情況，看看比較適合哪一種，是側重強一致性還是最終一致性。