1. 常用分散式事務解決方案

1.1 兩階段提交

一個基於兩階段提交協議的分散式事務框架

二階段提交(Two-phaseCommit)是指，在計算機網路以及資料庫領域內，為了使基於分散式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種演算法(Algorithm)。通常，二階段提交也被稱為是一種協議(Protocol))。在分散式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的元件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的資料寫入磁碟等等)。因此，二階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

• 所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。

1.1.1 準備階段

• 事務協調者(事務管理器)給每個參與者(資源管理器)傳送Prepare訊息，每個參與者要麼直接返回失敗(如許可權驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種“萬事俱備，只欠東風”的狀態。
• 一般講準備階段分為以下三個階段
  
  1. 協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。
  2. 參與者節點執行詢問發起為止的所有事務操作，並將Undo資訊和Redo資訊寫入日誌。（注意：若成功這裡其實每個參與者已經執行了事務操作）
  3. 各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”訊息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”訊息。

1.1.2 提交階段

• 如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(Rollback)訊息；否則，傳送提交(Commit)訊息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)
• 當協調者節點從所有參與者節點獲得的相應訊息都為”同意”時:
  
  1. 協調者節點向所有參與者節點發出”正式提交(commit)”的請求。
  2. 參與者節點正式完成操作，並釋放在整個事務期間內佔用的資源。
  3. 參與者節點向協調者節點傳送”完成”訊息。
  4. 協調者節點受到所有參與者節點反饋的”完成”訊息後，完成事務。

• 如果任一參與者節點在第一階段返回的響應訊息為”中止”，或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：
  
  1. 協調者節點向所有參與者節點發出”回滾操作(rollback)”的請求。
  2. 參與者節點利用之前寫入的Undo資訊執行回滾，並釋放在整個事務期間內佔用的資源。
  3. 參與者節點向協調者節點傳送”回滾完成”訊息。
  4. 協調者節點受到所有參與者節點反饋的”回滾完成”訊息後，取消事務。

1.1.3 兩階段提交的缺陷

1. 同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
2. 單點故障。由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者當機導致的參與者處於阻塞狀態的問題）
3. 資料不一致。在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了區域性網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分散式系統便出現了資料部一致性的現象。
4. 二階段無法解決的問題：協調者再發出commit訊息之後當機，而唯一接收到這條訊息的參與者同時也當機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

1.2 三階段提交

• 三階段提交（Three-phase commit），也叫三階段提交協議（Three-phase commit protocol），是二階段提交（2PC）的改進版本。

1.2.1 與兩階段提交的不同點

1. 引入超時機制。同時在協調者和參與者中都引入超時機制。
2. 在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。

也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

1. 相對於2PC，3PC主要解決的單點故障問題，並減少阻塞，因為一旦參與者無法及時收到來自協調者的資訊之後，他會預設執行commit。而不會一直持有事務資源並處於阻塞狀態。但是這種機制也會導致資料一致性問題，因為，由於網路原因，協調者傳送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在資料不一致的情況。

1.2.2 CanCommit階段

• 3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者傳送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應
  1.事務詢問 協調者向參與者傳送CanCommit請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應。
  2.響應反饋 參與者接到CanCommit請求之後，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，並進入預備狀態。否則反饋No

1.2.3 PreCommit階段

• 假如協調者從所有的參與者獲得的反饋都是Yes響應，那麼就會執行事務的預執行。
  
  1. 傳送預提交請求 協調者向參與者傳送PreCommit請求，並進入Prepared階段。
  2. 事務預提交 參與者接收到PreCommit請求後，會執行事務操作，並將undo和redo資訊記錄到事務日誌中。
  3. 響應反饋 如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。
• 假如有任何一個參與者向協調者傳送了No響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。
  
  1. 傳送中斷請求 協調者向所有參與者傳送abort請求。
  2. 中斷事務 參與者收到來自協調者的abort請求之後（或超時之後，仍未收到協調者的請求），執行事務的中斷。

1.2.4 doCommit階段

• 執行提交
  
  1. 傳送提交請求 協調接收到參與者傳送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送doCommit請求。
  2. 事務提交 參與者接收到doCommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
  3. 響應反饋 事務提交完之後，向協調者傳送Ack響應。
  4. 完成事務 協調者接收到所有參與者的ack響應之後，完成事務。
• 中斷事務 協調者沒有接收到參與者傳送的ACK響應（可能是接受者傳送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。
  
  1. 傳送中斷請求 協調者向所有參與者傳送abort請求
  2. 事務回滾 參與者接收到abort請求之後，利用其在階段二記錄的undo資訊來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。
  3. 反饋結果 參與者完成事務回滾之後，向協調者傳送ACK訊息
  4. 中斷事務 協調者接收到參與者反饋的ACK訊息之後，執行事務的中斷。

在doCommit階段，如果參與者無法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時之後，會繼續進行事務的提交。（其實這個應該是基於概率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那麼協調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當進入第三階段時，由於網路超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的機率很大。 ）

1.3 CAP定理

1.3.1 標準分散式事務缺陷

• 效率非常低
  
  1. 全域性事務方式下，全域性事務管理器（TM）通過XA介面使用二階段提交協議（ 2PC ）與資源層（如資料庫）進行互動。使用全域性事務，資料被Lock的時間跨整個事務，直到全域性事務結束。
  2. 2PC 是反可伸縮模式，在事務處理過程中，參與者需要一直持有資源直到整個分散式事務結束。這樣，當業務規模越來越大的情況下，2PC 的侷限性就越來越明顯，系統可伸縮性會變得很差。
  3. 與本地事務相比，XA 協議的系統開銷相當大，因而應當慎重考慮是否確實需要分散式事務。而且只有支援 XA 協議的資源才能參與分散式事務。

1.3.2 CAP理論詳解

• CAP原則是NOSQL資料庫的基石。
• CAP原則又稱CAP定理，指的是在一個分散式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性），三者不可得兼。
  
  1. 一致性（C）：在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）
  2. 可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）
  3. 分割槽容忍性（P）：以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。(容忍網路中斷)

1.4 BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模網際網路系統分散式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。接下來我們著重對BASE中的三要素進行詳細講解。

• BA: Basic Availability 基本業務可用性（支援分割槽失敗）:分散式系統在出現不可預知故障的時候，允許損失部分可用性
  
  • 響應時間上的損失：正常情況下，一個線上搜尋引擎需要0.5秒內返回給使用者相應的查詢結果，但由於出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。
  • 功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
• S: Soft state 柔性狀態（狀態允許有短時間不同步，非同步）
• E: Eventual consistency 最終一致性（最終資料是一致的，但不是實時一致）
  
  • 因果一致性：因果一致性是指，如果程式A在更新完某個資料項後通知了程式B，那麼程式B之後對該資料項的訪問都應該能夠獲取到程式A更新後的最新值，並且如果程式B要對該資料項進行更新操作的話，務必基於程式A更新後的最新值，即不能發生丟失更新情況。與此同時，與程式A無因果關係的程式C的資料訪問則沒有這樣的限制。
  • 讀己之所寫：讀己之所寫是指，程式A更新一個資料項之後，它自己總是能夠訪問到更新過的最新值，而不會看到舊值。也就是說，對於單個資料獲取者而言，其讀取到的資料一定不會比自己上次寫入的值舊。因此，讀己之所寫也可以看作是一種特殊的因果一致性。
  • 會話一致性：會話一致性將對系統資料的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現“讀己之所寫”的一致性，也就是說，執行更新操作之後，客戶端能夠在同一個會話中始終讀取到該資料項的最新值。
  • 單調讀一致性：單調讀一致性是指如果一個程式從系統中讀取出一個資料項的某個值後，那麼系統對於該程式後續的任何資料訪問都不應該返回更舊的值。
  • 單調寫一致性：單調寫一致性是指，一個系統需要能夠保證來自同一個程式的寫操作被順序地執行。

原子性（A）與永續性（D）必須根本保障
為了可用性、效能與降級服務的需要，只有降低一致性( C ) 與 隔離性( I ) 的要求

1.5 柔性事務

1.5.1 柔性事務中的服務模式

服務模式是柔性事務流程中的特殊操作實現（實現上對應業務服務要提供相應模式的功能介面），還不算是某一種柔性事務解決方案。

• 可查詢操作
  
  • 服務操作的可標識性
    
    • 服務操作具有全域性唯一標識(可以使用業務單據號/使用系統分配的操作流水號使用操作資源的組合組合標識)
    • 操作有唯一的、確定的時間
  • 單筆查詢
    
    • 使用全域性唯一的服務操作標識，查詢操作執行結果
    • 注意狀態判斷，小心“處理中”的狀態
  • 批量查詢
    
    • 使用時間區段與(或)一組服務操作的標識，查詢一批操作執行結果
• 冪等操作
  
  • 冪等性:f(f(x)) = f(x)
  • 冪等操作:重複呼叫多次產生的業務結果與呼叫一次產生的業務結果相同
  • 實現方式一:通過業務操作本身實現冪等性
  • 實現方式二:系統快取所有請求與處理結果,檢測到重複請求之後，自動返回之前的處理結果
• TCC操作
  
  • Try: 嘗試執行業務
    
    • 完成所有業務檢查(一致性)
    • 預留必須業務資源(準隔離性)
  • Confirm:確認執行業務
    
    • 真正執行業務
    • 不作任何業務檢查
    • 只使用Try階段預留的業務資源
    • Confirm操作要滿足冪等性
  • Cancel: 取消執行業務
    
    • 釋放Try階段預留的業務資源
    • Cancel操作要滿足冪等性
  • 與2PC協議比較
    
    • 位於業務服務層而非資源層
    • 沒有單獨的準備(Prepare)階段，Try操作兼備資源操作與準備能力
    • Try操作可以靈活選擇業務資源的鎖定粒度(以業務定粒度)
    • 較高開發成本

很多人把兩階段型操作等同於兩階段提交協議2PC操作。其實TCC操作也屬於兩階段型操作。

• 可補償操作
  
  • do: 真正執行業務
    
    • 完成業務處理
    • 業務執行結果外部可見
  • compensate:業務補償
    
    • 抵銷(或部分抵銷)正向業務操作的業務結果
    • 補償操作滿足冪等性
  • 約束
    
    • 補償在業務上可行
    • 由於業務執行結果未隔離、或者補償不完整帶來的風險與成本可控

TCC操作中的Confirm操作和Cancel操作，其實也可以看作是補償操作

1.5.1 柔性事務解決方案:最終一致性(可靠訊息/非同步確保型)

• 實現
  
  • 業務處理服務在業務事務提交前，向實時訊息服務請求傳送訊息，實時訊息服務只記錄訊息資料，而不真正傳送。業務處理服務在業務事務提交後，向實時訊息服務確認傳送。只有在得到確認傳送指令後，實時訊息服務才真正傳送
  • 業務處理服務在業務事務回滾後，向實時訊息服務取消傳送。訊息狀態確認系統定期找到未確認傳送或回滾傳送的訊息，向業務處理服務詢問訊息狀態，業務處理服務根據訊息ID或訊息內容確定該訊息是否有效
• 約束
  
  • 被動方的處理結果不影響主動方的處理結果， 被動方的訊息處理操作是冪等操作
• 成本
  
  • 可靠訊息系統建設成本
  • 一次訊息傳送需要兩次請求，業務處理服務需實現訊息狀態回查介面
• 優點、適用範圍
  
  • 訊息資料獨立儲存、獨立伸縮，降低業務系統與訊息系統間的耦合
  • 對最終一致性時間敏感度較高，降低業務被動方實現成本
• 用到的服務模式:可查詢操作、冪等操作
• 方案特點
  
  • 相容所有實現JMS標準的MQ中介軟體（本教程中實現的方案）
  • 確保業務資料可靠的前提下，實現業務資料的最終一致（理想狀態下基本是準實時一致）

1.5.2 柔性事務解決方案:TCC(兩階段型/補償型)

• 實現
  
  • 一個完整的業務活動由一個主業務服務與若干從業務服務組成
  • 主業務服務負責發起並完成整個業務活從業務服務提供TCC型業務操作
  • 業務活動管理器控制業務活動的一致性，它登記業務活動中的操作， 並在業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消時呼叫所有TCC型操作的cancel操作
• 成本
  
  • 實現TCC操作的成本
  • 業務活動結束時confirm或cancel操作的執行成本
  • 業務活動日誌成本
• 適用範圍
  
  • 強隔離性、嚴格一致性要求的業務活動
  • 適用於執行時間較短的業務（比如處理賬戶、收費等業務）
• 用到的服務模式:TCC操作、冪等操作、可補償操作、 可查詢操作
• 方案特點:
  
  • 不與具體的服務框架耦合（在RPC架構中通用）
  • 位於業務服務層，而非資源層
  • 可以靈活選擇業務資源的鎖定粒度
  • TCC裡對每個服務資源操作的是本地事務，資料被lock的時間短，可擴充套件性好（可以說是為獨立部署的SOA服務而設計的）

1.5.3 柔性事務解決方案:最大努力通知型(定期校對)

• 實現
  
  • 業務活動的主動方，在完成業務處理之後，向業務活動的被動方傳送訊息，允許訊息丟失。
  • 業務活動的被動方根據定時策略，向業務活動主動方查詢，恢復丟失的業務訊息。
• 約束:被動方的處理結果不影響主動方的處理結果
• 成本:業務查詢與校對系統的建設成本
• 適用範圍
  
  • 對業務最終一致性的時間敏感度低
  • 跨企業的業務活動
• 用到的服務模式:可查詢操作
• 方案特點
  
  • 業務活動的主動方在完成業務處理後，向業務活動被動方傳送通知訊息（允許訊息丟失）
  • 主動方可以設定時間階梯型通知規則，在通知失敗後按規則重複通知，直到通知N次後不再通知
  • 主動方提供校對查詢介面給被動方按需校對查詢，用於恢復丟失的業務訊息
• 行業應用案例:銀行通知、商戶通知等

1.6 總結

• 剛性事務
  
  • 全域性事務（標準的分散式事務）
• 柔性事務
  
  • 可靠訊息最終一致（非同步確何型）
  • TCC （兩階段型、補償型）
  • 最大努力通知（非可靠訊息 、 定期校對）
  • 純補償型（略）