一、分布式事務(wù)前奏

?

事務(wù)：事務(wù)是由一組操作構(gòu)成的可靠的獨立的工作單元，事務(wù)具備ACID的特性，即原子性、一致性、隔離性和持久性。

?

本地事務(wù)：當事務(wù)由資源管理器本地管理時被稱作本地事務(wù)。本地事務(wù)的優(yōu)點就是支持嚴格的ACID特性，高效，可靠，狀態(tài)可以只在資源管理器中維護，而且應用編程模型簡單。但是本地事務(wù)不具備分布式事務(wù)的處理能力，隔離的最小單位受限于資源管理器。

?

全局事務(wù)：當事務(wù)由全局事務(wù)管理器進行全局管理時成為全局事務(wù)，事務(wù)管理器負責管理全局的事務(wù)狀態(tài)和參與的資源，協(xié)同資源的一致提交回滾。

?

TX協(xié)議：應用或者應用服務(wù)器與事務(wù)管理器的接口。

?

XA協(xié)議：全局事務(wù)管理器與資源管理器的接口。XA是由X/Open組織提出的分布式事務(wù)規(guī)范。該規(guī)范主要定義了全局事務(wù)管理器和局部資源管理器之間的接口。主流的數(shù)據(jù)庫產(chǎn)品都實現(xiàn)了XA接口。

?

XA接口是一個雙向的系統(tǒng)接口，在事務(wù)管理器以及多個資源管理器之間作為通信橋梁。之所以需要XA是因為在分布式系統(tǒng)中從理論上講兩臺機器是無法達到一致性狀態(tài)的，因此引入一個單點進行協(xié)調(diào)。由全局事務(wù)管理器管理和協(xié)調(diào)的事務(wù)可以跨越多個資源和進程。全局事務(wù)管理器一般使用XA二階段協(xié)議與數(shù)據(jù)庫進行交互。

?

AP：應用程序，可以理解為使用DTP（Data Tools Platform）的程序。

?

RM：資源管理器，這里可以是一個DBMS或者消息服務(wù)器管理系統(tǒng)，應用程序通過資源管理器對資源進行控制，資源必須實現(xiàn)XA定義的接口。資源管理器負責控制和管理實際的資源。

?

TM：事務(wù)管理器，負責協(xié)調(diào)和管理事務(wù)，提供給AP編程接口以及管理資源管理器。事務(wù)管理器控制著全局事務(wù)，管理事務(wù)的生命周期，并且協(xié)調(diào)資源。

?

兩階段提交協(xié)議：XA用于在全局事務(wù)中協(xié)調(diào)多個資源的機制。TM和RM之間采取兩階段提交的方案來解決一致性問題。兩節(jié)點提交需要一個協(xié)調(diào)者（TM）來掌控所有參與者（RM）節(jié)點的操作結(jié)果并且指引這些節(jié)點是否需要最終提交。兩階段提交的局限在于協(xié)議成本，準備階段的持久成本，全局事務(wù)狀態(tài)的持久成本，潛在故障點多帶來的脆弱性，準備后，提交前的故障引發(fā)一系列隔離與恢復難題。

?

BASE理論：BA指的是基本業(yè)務(wù)可用性，支持分區(qū)失敗，S表示柔性狀態(tài)，也就是允許短時間內(nèi)不同步，E表示最終一致性，數(shù)據(jù)最終是一致的，但是實時是不一致的。原子性和持久性必須從根本上保障，為了可用性、性能和服務(wù)降級的需要，只有降低一致性和隔離性的要求。

?

CAP定理：對于共享數(shù)據(jù)系統(tǒng)，最多只能同時擁有CAP其中的兩個，任意兩個都有其適應的場景，真是的業(yè)務(wù)系統(tǒng)中通常是ACID與CAP的混合體。分布式系統(tǒng)中最重要的是滿足業(yè)務(wù)需求，而不是追求高度抽象，絕對的系統(tǒng)特性。C表示一致性，也就是所有用戶看到的數(shù)據(jù)是一樣的。A表示可用性，是指總能找到一個可用的數(shù)據(jù)副本。P表示分區(qū)容錯性，能夠容忍網(wǎng)絡(luò)中斷等故障。

?

柔性事務(wù)中的服務(wù)模式：

?

1）可查詢操作：服務(wù)操作具有全局唯一的標識，操作唯一的確定的時間。

?

2）冪等操作：重復調(diào)用多次產(chǎn)生的業(yè)務(wù)結(jié)果與調(diào)用一次產(chǎn)生的結(jié)果相同。一是通過業(yè)務(wù)操作實現(xiàn)冪等性，二是系統(tǒng)緩存所有請求與處理的結(jié)果，最后是檢測到重復請求之后，自動返回之前的處理結(jié)果。

?

3）TCC操作：

?

• Try階段：嘗試執(zhí)行業(yè)務(wù)，完成所有業(yè)務(wù)的檢查，實現(xiàn)一致性；預留必須的業(yè)務(wù)資源，實現(xiàn)準隔離性。

• Confirm階段：真正的去執(zhí)行業(yè)務(wù)，不做任何檢查，僅適用Try階段預留的業(yè)務(wù)資源，Confirm操作還要滿足冪等性；

• Cancel階段：取消執(zhí)行業(yè)務(wù)，釋放Try階段預留的業(yè)務(wù)資源，Cancel操作要滿足冪等性。

?

TCC與2PC(兩階段提交)協(xié)議的區(qū)別：TCC位于業(yè)務(wù)服務(wù)層而不是資源層，TCC沒有單獨準備階段，Try操作兼?zhèn)滟Y源操作與準備的能力，TCC中Try操作可以靈活的選擇業(yè)務(wù)資源，鎖定粒度。TCC的開發(fā)成本比2PC高。實際上TCC也屬于兩階段操作，但是TCC不等同于2PC操作。

?

4）可補償操作：

?

• Do階段：真正的執(zhí)行業(yè)務(wù)處理，業(yè)務(wù)處理結(jié)果外部可見；

• Compensate階段：抵消或者部分撤銷正向業(yè)務(wù)操作的業(yè)務(wù)結(jié)果，補償操作滿足冪等性。

• 約束：補償操作在業(yè)務(wù)上可行，由于業(yè)務(wù)執(zhí)行結(jié)果未隔離或者補償不完整帶來的風險與成本可控。實際上，TCC的Confirm和Cancel操作可以看做是補償操作。

?

二、柔性事務(wù)解決方案架構(gòu)

?

在電商領(lǐng)域等互聯(lián)網(wǎng)場景下，傳統(tǒng)的事務(wù)在數(shù)據(jù)庫性能和處理能力上都暴露出了瓶頸。柔性事務(wù)有兩個特性：基本可用和柔性狀態(tài)。

?

所謂基本可用是指分布式系統(tǒng)出現(xiàn)故障的時候允許損失一部分的可用性。柔性狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，這個中間狀態(tài)不會影響系統(tǒng)整體的可用性，比如數(shù)據(jù)庫讀寫分離的主從同步延遲等。柔性事務(wù)的一致性指的是最終一致性。

?

基于可靠消息的最終一致性方案

?

?

1）實現(xiàn)：業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交之前，向?qū)崟r消息服務(wù)請求發(fā)送消息，實時消息服務(wù)只記錄消息數(shù)據(jù)，而不是真正的發(fā)送。業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交之后，向?qū)崟r消息服務(wù)確認發(fā)送。只有在得到確認發(fā)送指令后，實時消息服務(wù)才會真正發(fā)送。

?

2）消息：業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)回滾后，向?qū)崟r消息服務(wù)取消發(fā)送。消息發(fā)送狀態(tài)確認系統(tǒng)定期找到未確認發(fā)送或者回滾發(fā)送的消息，向業(yè)務(wù)處理服務(wù)詢問消息狀態(tài)，業(yè)務(wù)處理服務(wù)根據(jù)消息ID或者消息內(nèi)容確認該消息是否有效。被動方的處理結(jié)果不會影響主動方的處理結(jié)果，被動方的消息處理操作是冪等操作。

?

3）成本：可靠的消息系統(tǒng)建設(shè)成本，一次消息發(fā)送需要兩次請求，業(yè)務(wù)處理服務(wù)需要實現(xiàn)消息狀態(tài)回查接口。

?

4）優(yōu)點：消息數(shù)據(jù)獨立存儲，獨立伸縮，降低業(yè)務(wù)系統(tǒng)和消息系統(tǒng)之間的耦合。對最終一致性時間敏感度較高，降低業(yè)務(wù)被動方的實現(xiàn)成本。兼容所有實現(xiàn)JMS標準的MQ中間件，確保業(yè)務(wù)數(shù)據(jù)可靠的前提下，實現(xiàn)業(yè)務(wù)的最終一致性，理想狀態(tài)下是準實時的一致性。

?

TCC事務(wù)補償型方案

?

?

1）實現(xiàn)：一個完整的業(yè)務(wù)活動由一個主業(yè)務(wù)服務(wù)于若干的從業(yè)務(wù)服務(wù)組成。主業(yè)務(wù)服務(wù)負責發(fā)起并完成整個業(yè)務(wù)活動。從業(yè)務(wù)服務(wù)提供TCC型業(yè)務(wù)操作。業(yè)務(wù)活動管理器控制業(yè)務(wù)活動的一致性，它登記業(yè)務(wù)活動的操作，并在業(yè)務(wù)活動提交時確認所有的TCC型操作的Confirm操作，在業(yè)務(wù)活動取消時調(diào)用所有TCC型操作的Cancel操作。

?

2）成本：實現(xiàn)TCC操作的成本較高，業(yè)務(wù)活動結(jié)束的時候Confirm和Cancel操作的執(zhí)行成本。業(yè)務(wù)活動的日志成本。

?

3）使用范圍：強隔離性，嚴格一致性要求的業(yè)務(wù)活動。適用于執(zhí)行時間較短的業(yè)務(wù)，比如處理賬戶或者收費等等。

?

4）特點：不與具體的服務(wù)框架耦合，位于業(yè)務(wù)服務(wù)層，而不是資源層，可以靈活的選擇業(yè)務(wù)資源的鎖定粒度。TCC里對每個服務(wù)資源操作的是本地事務(wù)，數(shù)據(jù)被鎖住的時間短，可擴展性好，可以說是為獨立部署的SOA服務(wù)而設(shè)計的。

?

最大努力通知型

?

?

1）實現(xiàn)：業(yè)務(wù)活動的主動方在完成處理之后向業(yè)務(wù)活動的被動方發(fā)送消息，允許消息丟失。業(yè)務(wù)活動的被動方根據(jù)定時策略，向業(yè)務(wù)活動的主動方查詢，恢復丟失的業(yè)務(wù)消息。

?

2）約束：被動方的處理結(jié)果不影響主動方的處理結(jié)果。

?

3）成本：業(yè)務(wù)查詢與校對系統(tǒng)的建設(shè)成本。

?

4）使用范圍：對業(yè)務(wù)最終一致性的時間敏感度低。跨企業(yè)的業(yè)務(wù)活動。

?

5）特點：業(yè)務(wù)活動的主動方在完成業(yè)務(wù)處理之后，向業(yè)務(wù)活動的被動方發(fā)送通知消息。主動方可以設(shè)置時間階梯通知規(guī)則，在通知失敗后按規(guī)則重復通知，知道通知N次后不再通知。主動方提供校對查詢接口給被動方按需校對查詢，用戶恢復丟失的業(yè)務(wù)消息。

?

適用范圍：銀行通知，商戶通知。

?

三、基于可靠消息的最終一致性方案

?

消息發(fā)送一致性

?

消息中間件在分布式系統(tǒng)中的核心作用就是異步通訊、應用解耦和并發(fā)緩沖（也叫作流量削峰）。在分布式環(huán)境下，需要通過網(wǎng)絡(luò)進行通訊，就引入了數(shù)據(jù)傳輸?shù)牟淮_定性，也就是CAP理論中的分區(qū)容錯性。

消息發(fā)送一致性是指產(chǎn)生消息的業(yè)務(wù)動作與消息發(fā)送一致，也就是說如果業(yè)務(wù)操作成功，那么由這個業(yè)務(wù)操作所產(chǎn)生的消息一定要發(fā)送出去，否則就丟失。

?

處理方式一：

?

public void completeOrderService() {

? ? // 處理訂單

? ? order.process();

?

? ? // 發(fā)送會計原始憑證消息

? ? pipe.sendAccountingVouchetMessage();

}

?

在上面的情況中，如果業(yè)務(wù)操作成功，執(zhí)行的消息發(fā)送之前應用發(fā)生故障，消息發(fā)送不出去，導致消息丟失，將會產(chǎn)生訂單系統(tǒng)與會計系統(tǒng)的數(shù)據(jù)不一致。如果消息系統(tǒng)或者網(wǎng)絡(luò)異常，也會導致消息發(fā)送不出去，也會造成數(shù)據(jù)不一致。

?

處理方式二：

?

public void completeOrderService() {

? ? // 發(fā)送會計原始憑證消息

? ? pipe.sendAccountingVouchetMessage();

?

? ? // 處理訂單

? ? order.process();

}

?

如果將上面的兩個操作調(diào)換一下順序，這種情況就會更加不可控了，消息發(fā)出去了業(yè)務(wù)訂單可能會失敗，會造成訂單系統(tǒng)與業(yè)務(wù)系統(tǒng)的數(shù)據(jù)不一致。那么JMS標準中的XA協(xié)議是否可以保障發(fā)送的一致性？

?

JMS協(xié)議標準的API中，有很多以XA開頭的接口，其實就是前面講到的支持XA協(xié)議（基于兩階段提交協(xié)議）的全局事務(wù)型接口。

?

XAConnection.class

XAConnectionFactory.class

XAQueueConnection.class

XAQueueConnectionFactory.class

XASession.class

XATopicConnection.class

XATopicConnectionFactory.class

XATopicSession.class

?

JMS中的XA系列的接口可以提供分布式事務(wù)的支持。但是引用XA方式的分布式事務(wù)，就會帶來很多局限性。

?

• 要求業(yè)務(wù)操作的資源必須支持XA協(xié)議，但是并不是所有的資源都支持XA協(xié)議。

• 兩階段提交協(xié)議的成本。

• 持久化成本等DTP模型的局限性，例如：全局鎖定、成本高、性能低。

• 使用XA協(xié)議違背了柔性事務(wù)的初衷。

?

保證消息一致的變通做法

?

?

1）發(fā)送消息：主動方現(xiàn)將應用把消息發(fā)給消息中間件，消息狀態(tài)標記為“待確認”狀態(tài)。

?

2）消息中間件收到消息后，把消息持久化到消息存儲中，但是并不影響被動方投遞消息。

?

3）消息中間件返回消息持久化結(jié)果，主動方根據(jù)返回的結(jié)果進行判斷如何進行業(yè)務(wù)操作處理：

?

• 失敗：放棄執(zhí)行業(yè)務(wù)操作處理，結(jié)束，必要時向上層返回處理結(jié)果；

• 成功：執(zhí)行業(yè)務(wù)操作處理。

?

4）業(yè)務(wù)操作完成后，把業(yè)務(wù)操作結(jié)果返回給消息中間件。消息中間件收到業(yè)務(wù)操作結(jié)構(gòu)后，根據(jù)業(yè)務(wù)結(jié)果進行處理：

?

• 失敗：刪除消息存儲中的消息，結(jié)束；

• 成功：更新消息存儲中的消息狀態(tài)為“待發(fā)送”，然后執(zhí)行消息投遞。

?

前面的正向流程都成功之后，向被動方應用投遞消息。但是在上面的處理流程中，任何一個環(huán)節(jié)都有可能出現(xiàn)問題。

?

常規(guī)MQ消息處理流程和特點

?

常規(guī)的MQ隊列處理流程無法實現(xiàn)消息的一致性。投遞消息的本質(zhì)就是消息消費，可以細化。

?

消息重復發(fā)送問題和業(yè)務(wù)接口冪等性設(shè)計

?

?

對于未確認的消息，采用按規(guī)則重新投遞的方式進行處理。對于以上流程，消息重復發(fā)送會導致業(yè)務(wù)處理接口出現(xiàn)重復調(diào)用的問題。

?

消息消費過程中消息重復發(fā)送的主要原因就是消費者成功接收處理完消息后，消息中間件沒有及時更新投遞狀態(tài)導致的。如果允許消息重復發(fā)送，那么消費方應該實現(xiàn)業(yè)務(wù)接口的冪等性設(shè)計。

?

本地消息服務(wù)方案

?

?

1）實現(xiàn)思路：

?

• 主動方應用系統(tǒng)通過業(yè)務(wù)操作完成業(yè)務(wù)數(shù)據(jù)的操作，在準備發(fā)送消息的時候?qū)⑾⒋鎯υ谥鲃臃綉孟到y(tǒng)一份，另一份發(fā)送到實時消息服務(wù)；

• 被動方應用系統(tǒng)監(jiān)聽實時消息系統(tǒng)中的消息，當被動方完成消息處理后通過調(diào)用主動方接口完成消息確認；

• 主動方接收到消息確認以后刪除消息數(shù)據(jù)；

• 通過消息查詢服務(wù)查詢到消息被接收之后再規(guī)定的時間內(nèi)沒有返回ACK確認消息就通過消息恢復系統(tǒng)重新發(fā)送消息。

?

2）優(yōu)點：

?

• 消息的時效性比較高；

• 從應用設(shè)計的角度實現(xiàn)了消息數(shù)據(jù)的可靠性，消息數(shù)據(jù)的可靠性不依賴于MQ中間件，弱化了對MQ中間件特性的依賴；

• 方案輕量級，容易實現(xiàn)。

?

3）缺點：

?

• 與具體的業(yè)務(wù)場景綁定，耦合性強，不可以共用；

• 消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)同步，占用業(yè)務(wù)系統(tǒng)資源；

• 業(yè)務(wù)系統(tǒng)在使用關(guān)系型數(shù)據(jù)庫的情況下消息服務(wù)性能會受到關(guān)系型數(shù)據(jù)庫的并發(fā)性能限制。

?

獨立消息服務(wù)方案

?

?

1）實現(xiàn)思路：

?

預發(fā)送消息：主動方應用系統(tǒng)預發(fā)送消息，由消息服務(wù)子系統(tǒng)存儲消息，如果存儲失敗，那么也就無法進行業(yè)務(wù)操作。如果返回存儲成功，然后執(zhí)行業(yè)務(wù)操作。

?

執(zhí)行業(yè)務(wù)操作：執(zhí)行業(yè)務(wù)操作如果成功的時候，將業(yè)務(wù)操作執(zhí)行成功的狀態(tài)發(fā)送到消息服務(wù)子系統(tǒng)。消息服務(wù)子系統(tǒng)修改消息的標識為“可發(fā)送”狀態(tài)。

?

發(fā)送消息到實時消息服務(wù)：當消息的狀態(tài)發(fā)生改變的時候，立刻將消息發(fā)送到實時消息服務(wù)中。接下來，消息將會被消息業(yè)務(wù)的消費端監(jiān)聽到，然后被消費。

?

消息狀態(tài)子系統(tǒng)：相當于定時任務(wù)系統(tǒng)，在消息服務(wù)子系統(tǒng)中定時查找確認超時的消息，在主動方應用系統(tǒng)中也去定時查找沒有處理成功的任務(wù)，進行相應的處理。

?

消息消費：當消息被消費的時候，向?qū)崟r消息服務(wù)發(fā)送ACK，然后實時消息服務(wù)刪除消息。同時調(diào)用消息服務(wù)子系統(tǒng)修改消息為“被消費”狀態(tài)。

?

消息恢復子系統(tǒng)：當消費方返回消息的時候，由于網(wǎng)絡(luò)中斷等其他原因?qū)е孪]有及時確認，那么需要消息恢復子系統(tǒng)定時查找出在消息服務(wù)子系統(tǒng)中沒有確認的消息。將沒有被確認的消息放到實時消息服務(wù)中，進行重做，因為被動方應用系統(tǒng)的接口是冪等的。

?

2）優(yōu)點：

?

• 消息服務(wù)獨立部署，獨立維護，獨立伸縮。

• 消息存儲可以按需選擇不同的數(shù)據(jù)庫來集成實現(xiàn)。

• 消息服務(wù)可以被相同的的使用場景使用，降低重復建設(shè)服務(wù)的成本。

• 從分布式服務(wù)應用設(shè)計開發(fā)角度實現(xiàn)了消息數(shù)據(jù)的可靠性，消息數(shù)據(jù)的可靠性不依賴于MQ中間件，弱化了對MQ中間件特性的依賴。

• 降低了業(yè)務(wù)系統(tǒng)與消息系統(tǒng)之間的耦合，有利于系統(tǒng)的擴展維護。

?

3）缺點：

?

• 一次消息發(fā)送需要兩次請求；

• 主動方應用系統(tǒng)需要實現(xiàn)業(yè)務(wù)操作狀態(tài)的校驗與查詢接口。

?

消息服務(wù)子系統(tǒng)的設(shè)計實現(xiàn)

?

示例消息數(shù)據(jù)表：

?

總結(jié)

以上是生活随笔為你收集整理的详解三种主流分布式事务方案的优劣的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。