分佈式事務中的三種解決方案詳解

時間 2019-11-07

原文原文鏈接

[TOC]java

1、分佈式事務前奏

事務：事務是由一組操做構成的可靠的獨立的工做單元，事務具有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操做能夠看作是補償操做。

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

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

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

實現：業務處理服務在業務事務提交以前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據，而不是真正的發送。業務處理服務在業務事務提交以後，向實時消息服務確認發送。只有在獲得確認發送指令後，實時消息服務纔會真正發送。
消息：業務處理服務在業務事務回滾後，向實時消息服務取消發送。消息發送狀態確認系統按期找到未確認發送或者回滾發送的消息，向業務處理服務詢問消息狀態，業務處理服務根據消息ID或者消息內容確認該消息是否有效。被動方的處理結果不會影響主動方的處理結果，被動方的消息處理操做是冪等操做。
成本：可靠的消息系統建設成本，一次消息發送須要兩次請求，業務處理服務須要實現消息狀態回查接口。
優勢：消息數據獨立存儲，獨立伸縮，下降業務系統和消息系統之間的耦合。對最終一致性時間敏感度較高，下降業務被動方的實現成本。兼容全部實現JMS標準的MQ中間件，確保業務數據可靠的前提下，實現業務的最終一致性，理想狀態下是準實時的一致性。

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

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

（三）、最大努力通知型

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

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

（一）、消息發送一致性

消息中間件在分佈式系統中的核心做用就是異步通信、應用解耦和併發緩衝（也叫做流量削峯）。在分佈式環境下，須要經過網絡進行通信，就引入了數據傳輸的不肯定性，也就是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. 成功：執行業務操做處理。
業務操做完成後，把業務操做結果返回給消息中間件。
消息中間件收到業務操做結構後，根據業務結果進行處理：
1. 失敗：刪除消息存儲中的消息，結束。
2. 成功：更新消息存儲中的消息狀態爲「待發送」，而後執行消息投遞。
前面的正向流程都成功以後，向被動方應用投遞消息。

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

（三）、常規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. 主動方應用系統須要實現業務操做狀態的校驗與查詢接口。

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

示例消息數據表：

名稱	數據類型	容許空	默認值	屬性	釋義
uuid	varchar(50)	No	—	unique	UUID
version	int(11)	No	0	—	版本號
editer	varchar(100)	Yes	NULL	—	修改者
creater	varchar(100)	Yes	NULL	—	建立者
edit_time	datetime	Yes	0000-00-00 00:00:00	—	最後修改時間
create_time	datetime	No	0000-00-00 00:00:00	—	建立時間
msg_id	varchar(50)	No	—	—	消息ID
msg_body	longtext	No	—	—	消息內容
msg_date_type	varchar(50)	Yes	—	—	消息數據類型
consumer_queue	varchar(100)	No	—	—	消費隊列
send_times	int(6)	No	0	—	消息重發次數
is_dead	varchar(20)	No	—	—	是否死亡
status	varchar(20)	No	—	—	狀態
remark	varchar(200)	Yes	—	—	備註
field0	varchar(200)	Yes	—	—	擴展字段0
field1	varchar(200)	Yes	—	—	擴展字段1
field2	varchar(200)	Yes	—	—	擴展字段2