• 一、分散式事務前奏
• 二、柔性事務解決方案架構
  • （一）、基於可靠訊息的最終一致性方案概述
  • （二）、TCC事務補償型方案
  • （三）、最大努力通知型
• 三、基於可靠訊息的最終一致性方案詳解
  • （一）、訊息傳送一致性
  • （二）、保證訊息一致的變通做法
  • （三）、常規MQ訊息處理流程和特點
  • （四）、訊息重複傳送問題和業務介面冪等性設計
  • （五）、本地訊息服務方案
  • （六）、獨立訊息服務方案
  • （七）、訊息服務子系統的設計實現

一、分散式事務前奏

• 事務：事務是由一組操作構成的可靠的獨立的工作單元，事務具備ACID的特性，即原子性、一致性、隔離性和永續性。
• 本地事務：當事務由資源管理器本地管理時被稱作本地事務。本地事務的優點就是支援嚴格的ACID特性，高效，可靠，狀態可以只在資源管理器中維護，而且應用程式設計模型簡單。但是本地事務不具備分散式事務的處理能力，隔離的最小單位受限於資源管理器。
• 全域性事務：當事務由全域性事務管理器進行全域性管理時成為全域性事務，事務管理器負責管理全域性的事務狀態和參與的資源，協同資源的一致提交回滾。
• TX協議：應用或者應用伺服器與事務管理器的介面。
• XA協議：全域性事務管理器與資源管理器的介面。XA是由X/Open組織提出的分散式事務規範。該規範主要定義了全域性事務管理器和區域性資源管理器之間的介面。主流的資料庫產品都實現了XA介面。XA介面是一個雙向的系統介面，在事務管理器以及多個資源管理器之間作為通訊橋樑。之所以需要XA是因為在分散式系統中從理論上講兩臺機器是無法達到一致性狀態的，因此引入一個單點進行協調。由全域性事務管理器管理和協調的事務可以跨越多個資源和程序。全域性事務管理器一般使用XA二階段協議與資料庫進行互動。
• AP：應用程式，可以理解為使用DTP（Data Tools Platform）的程式。
• RM：資源管理器，這裡可以是一個DBMS或者訊息伺服器管理系統，應用程式通過資源管理器對資源進行控制，資源必須實現XA定義的介面。資源管理器負責控制和管理實際的資源。
• TM：事務管理器，負責協調和管理事務，提供給AP程式設計介面以及管理資源管理器。事務管理器控制著全域性事務，管理事務的生命週期，並且協調資源。
• 兩階段提交協議：XA用於在全域性事務中協調多個資源的機制。TM和RM之間採取兩階段提交的方案來解決一致性問題。兩節點提交需要一個協調者（TM）來掌控所有參與者（RM）節點的操作結果並且指引這些節點是否需要最終提交。兩階段提交的侷限在於協議成本，準備階段的持久成本，全域性事務狀態的持久成本，潛在故障點多帶來的脆弱性，準備後，提交前的故障引發一系列隔離與恢復難題。
• BASE理論：BA指的是基本業務可用性，支援分割槽失敗，S表示柔性狀態，也就是允許短時間內不同步，E表示最終一致性，資料最終是一致的，但是實時是不一致的。原子性和永續性必須從根本上保障，為了可用性、效能和服務降級的需要，只有降低一致性和隔離性的要求。
• CAP定理：對於共享資料系統，最多隻能同時擁有CAP其中的兩個，任意兩個都有其適應的場景，真是的業務系統中通常是ACID與CAP的混合體。分散式系統中最重要的是滿足業務需求，而不是追求高度抽象，絕對的系統特性。C表示一致性，也就是所有使用者看到的資料是一樣的。A表示可用性，是指總能找到一個可用的資料副本。P表示分割槽容錯性，能夠容忍網路中斷等故障。
• 柔性事務中的服務模式：
  1. 可查詢操作：服務操作具有全域性唯一的標識，操作唯一的確定的時間。
  2. 冪等操作：重複呼叫多次產生的業務結果與呼叫一次產生的結果相同。一是通過業務操作實現冪等性，二是系統快取所有請求與處理的結果，最後是檢測到重複請求之後，自動返回之前的處理結果。
  3. TCC操作：Try階段，嘗試執行業務，完成所有業務的檢查，實現一致性；預留必須的業務資源，實現準隔離性。Confirm階段：真正的去執行業務，不做任何檢查，僅適用Try階段預留的業務資源，Confirm操作還要滿足冪等性。Cancel階段：取消執行業務，釋放Try階段預留的業務資源，Cancel操作要滿足冪等性。TCC與2PC(兩階段提交)協議的區別：TCC位於業務服務層而不是資源層，TCC沒有單獨準備階段，Try操作兼備資源操作與準備的能力，TCC中Try操作可以靈活的選擇業務資源，鎖定粒度。TCC的開發成本比2PC高。實際上TCC也屬於兩階段操作，但是TCC不等同於2PC操作。
  4. 可補償操作：Do階段：真正的執行業務處理，業務處理結果外部可見。Compensate階段：抵消或者部分撤銷正向業務操作的業務結果，補償操作滿足冪等性。約束：補償操作在業務上可行，由於業務執行結果未隔離或者補償不完整帶來的風險與成本可控。實際上，TCC的Confirm和Cancel操作可以看做是補償操作。

二、柔性事務解決方案架構

在電商領域等網際網路場景下，傳統的事務在資料庫效能和處理能力上都暴露出了瓶頸。柔性事務有兩個特性：基本可用和柔性狀態。所謂基本可用是指分散式系統出現故障的時候允許損失一部分的可用性。柔性狀態是指允許系統存在中間狀態，這個中間狀態不會影響系統整體的可用性，比如資料庫讀寫分離的主從同步延遲等。柔性事務的一致性指的是最終一致性。

（一）、基於可靠訊息的最終一致性方案概述

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

（二）、TCC事務補償型方案

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

（三）、最大努力通知型

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

三、基於可靠訊息的最終一致性方案詳解

（一）、訊息傳送一致性

訊息中介軟體在分散式系統中的核心作用就是非同步通訊、應用解耦和併發緩衝（也叫作流量削峰）。在分散式環境下，需要通過網路進行通訊，就引入了資料傳輸的不確定性，也就是CAP理論中的分割槽容錯性。

訊息傳送一致性是指產生訊息的業務動作與訊息傳送一致，也就是說如果業務操作成功，那麼由這個業務操作所產生的訊息一定要傳送出去，否則就丟失。

處理方式一

public void completeOrderService() {
	// 處理訂單
	order.process();
    
	// 傳送會計原始憑證訊息
	pipe.sendAccountingVouchetMessage();
}

在上面的情況中，如果業務操作成功，執行的訊息傳送之前應用發生故障，訊息傳送不出去，導致訊息丟失，將會產生訂單系統與會計系統的資料不一致。如果訊息系統或者網路異常，也會導致訊息傳送不出去，也會造成資料不一致。

處理方式二

public void completeOrderService() {
	// 傳送會計原始憑證訊息
	pipe.sendAccountingVouchetMessage();
	
	// 處理訂單
	order.process();
}

如果將上面的兩個操作調換一下順序，這種情況就會更加不可控了，訊息發出去了業務訂單可能會失敗，會造成訂單系統與業務系統的資料不一致。那麼JMS標準中的XA協議是否可以保障傳送的一致性？

• JMS協議標準的API中，有很多以XA開頭的介面，其實就是前面講到的支援XA協議（基於兩階段提交協議）的全域性事務型介面。

  XAConnection.class
  XAConnectionFactory.class
  XAQueueConnection.class
  XAQueueConnectionFactory.class
  XASession.class
  XATopicConnection.class
  XATopicConnectionFactory.class
  XATopicSession.class
  

• JMS中的XA系列的介面可以提供分散式事務的支援。但是引用XA方式的分散式事務，就會帶來很多侷限性。

  1. 要求業務操作的資源必須支援XA協議，但是並不是所有的資源都支援XA協議。
  2. 兩階段提交協議的成本。
  3. 持久化成本等DTP模型的侷限性，例如：全域性鎖定、成本高、效能低。
  4. 使用XA協議違背了柔性事務的初衷。

（二）、保證訊息一致的變通做法

1. 傳送訊息：主動方現將應用把訊息發給訊息中介軟體，訊息狀態標記為“待確認”狀態。
2. 訊息中介軟體收到訊息後，把訊息持久化到訊息儲存中，但是並不影響被動方投遞訊息。
3. 訊息中介軟體返回訊息持久化結果，主動方根據返回的結果進行判斷如何進行業務操作處理：
   1. 失敗：放棄執行業務操作處理，結束，必要時向上層返回處理結果。
   2. 成功：執行業務操作處理。
4. 業務操作完成後，把業務操作結果返回給訊息中介軟體。
5. 訊息中介軟體收到業務操作結構後，根據業務結果進行處理：
   1. 失敗：刪除訊息儲存中的訊息，結束。
   2. 成功：更新訊息儲存中的訊息狀態為“待發送”，然後執行訊息投遞。
6. 前面的正向流程都成功之後，向被動方應用投遞訊息。

但是在上面的處理流程中，任何一個環節都有可能出現問題。

（三）、常規MQ訊息處理流程和特點

• 常規的MQ佇列處理流程無法實現訊息的一致性。
• 投遞訊息的本質就是訊息消費，可以細化。

（四）、訊息重複傳送問題和業務介面冪等性設計

對於未確認的訊息，採用按規則重新投遞的方式進行處理。對於以上流程，訊息重複傳送會導致業務處理接口出現重複呼叫的問題。訊息消費過程中訊息重複傳送的主要原因就是消費者成功接收處理完訊息後，訊息中介軟體沒有及時更新投遞狀態導致的。如果允許訊息重複傳送，那麼消費方應該實現業務介面的冪等性設計。

（五）、本地訊息服務方案

• 實現思路：
  1. 主動方應用系統通過業務操作完成業務資料的操作，在準備傳送訊息的時候將訊息儲存在主動方應用系統一份，另一份傳送到實時訊息服務
  2. 被動方應用系統監聽實時訊息系統中的訊息，當被動方完成訊息處理後通過呼叫主動方介面完成訊息確認
  3. 主動方接收到訊息確認以後刪除訊息資料。
  4. 通過訊息查詢服務查詢到訊息被接收之後再規定的時間內沒有返回ACK確認訊息就通過訊息恢復系統重新發送訊息。
• 優點：
  1. 訊息的時效性比較高
  2. 從應用設計的角度實現了訊息資料的可靠性，訊息資料的可靠性不依賴於MQ中介軟體，弱化了對MQ中介軟體特性的依賴。
  3. 方案輕量級，容易實現。
• 缺點：
  1. 與具體的業務場景繫結，耦合性強，不可以共用。
  2. 訊息資料與業務資料同步，佔用業務系統資源。
  3. 業務系統在使用關係型資料庫的情況下訊息服務效能會受到關係型資料庫的併發效能限制。

（六）、獨立訊息服務方案

• 實現思路：
  1. 預傳送訊息：主動方應用系統預傳送訊息，由訊息服務子系統儲存訊息，如果儲存失敗，那麼也就無法進行業務操作。如果返回儲存成功，然後執行業務操作。
  2. 執行業務操作：執行業務操作如果成功的時候，將業務操作執行成功的狀態傳送到訊息服務子系統。訊息服務子系統修改訊息的標識為“可傳送”狀態。
  3. 傳送訊息到實時訊息服務：當訊息的狀態發生改變的時候，立刻將訊息傳送到實時訊息服務中。接下來，訊息將會被訊息業務的消費端監聽到，然後被消費。
  4. 訊息狀態子系統：相當於定時任務系統，在訊息服務子系統中定時查詢確認超時的訊息，在主動方應用系統中也去定時查詢沒有處理成功的任務，進行相應的處理。
  5. 訊息消費：當訊息被消費的時候，向實時訊息服務傳送ACK，然後實時訊息服務刪除訊息。同時呼叫訊息服務子系統修改訊息為“被消費”狀態。
  6. 訊息恢復子系統：當消費方返回訊息的時候，由於網路中斷等其他原因導致訊息沒有及時確認，那麼需要訊息恢復子系統定時查找出在訊息服務子系統中沒有確認的訊息。將沒有被確認的訊息放到實時訊息服務中，進行重做，因為被動方應用系統的介面是冪等的。
• 優點：
  1. 訊息服務獨立部署，獨立維護，獨立伸縮。
  2. 訊息儲存可以按需選擇不同的資料庫來整合實現。
  3. 訊息服務可以被相同的的使用場景使用，降低重複建設服務的成本。
  4. 從分散式服務應用設計開發角度實現了訊息資料的可靠性，訊息資料的可靠性不依賴於MQ中介軟體，弱化了對MQ中介軟體特性的依賴。
  5. 降低了業務系統與訊息系統之間的耦合，有利於系統的擴充套件維護。
• 缺點：
  1. 一次訊息傳送需要兩次請求。
  2. 主動方應用系統需要實現業務操作狀態的校驗與查詢介面。

（七）、訊息服務子系統的設計實現

示例訊息資料表：