首先我們來了解一下分布式事務(wù)模型：

TCC 模型：TCC-Transaction、Hmily

XA 模型：Sharding Sphere、MyCAT

2PC 模型：raincat、lcn

MQ 模型：RocketMQ

BED 模型：Sharding Sphere

Saga 模型：ServiceComb Saga

TCC

TCC事務(wù)解決方案本質(zhì)上是一種補(bǔ)償?shù)乃悸罚咽聞?wù)運(yùn)行過程分成try、confirm/cancel 兩個(gè)階段，每個(gè)階段都由業(yè)務(wù)代碼來控制。需要注意的是，TCC事務(wù)和2pc的思想類似，但與2pc實(shí)現(xiàn)不同，TCC不再是兩階段提交，而只是它對(duì)事務(wù)的提交/回滾是通過執(zhí)行一段confirm/cancel業(yè)務(wù)邏輯來實(shí)現(xiàn)，并且也并沒有全局事務(wù)來把控整個(gè)事務(wù)邏輯。

實(shí)現(xiàn)過程：

try：完成所有業(yè)務(wù)檢查(一致性)，預(yù)留業(yè)務(wù)資源。

confirm：確認(rèn)執(zhí)行業(yè)務(wù)操作，只使用try階段預(yù)留的業(yè)務(wù)資源。

cancel：取消try階段預(yù)留的業(yè)務(wù)資源。

XA模型(規(guī)范)

xa是個(gè)規(guī)范，根據(jù)這個(gè)思想衍生二階段提交協(xié)議和三階段提交協(xié)議。

XA分布式事務(wù)是由一個(gè)或者多個(gè)Resource Managerd，一個(gè)事務(wù)管理器Transaction Manager以及一個(gè)應(yīng)用程序 Application Program組成。

資源管理器：提供訪問事務(wù)資源的方法，通常一個(gè)數(shù)據(jù)庫就是一個(gè)資源管理器。

事務(wù)管理器：協(xié)調(diào)參與全局事務(wù)中的各個(gè)事務(wù)。需要和參與全局事務(wù)中的資源管理器進(jìn)行通信。

應(yīng)用程序：定義事務(wù)的邊界，指定全局事務(wù)中的操作。

2pc

二階段提交是分布式事務(wù)的重要的一個(gè)關(guān)鍵點(diǎn)，二階段提交協(xié)議包含了兩個(gè)階段：第一階段(也稱準(zhǔn)備階段)和第二階段(也稱提交階段)。

準(zhǔn)備階段：準(zhǔn)備階段，每個(gè)資源管理器都會(huì)被輪訓(xùn)一遍，事務(wù)管理器給每個(gè)資源管理器發(fā)送Prepare消息，每個(gè)資源管理器要么直接返回失敗(如權(quán)限驗(yàn)證失敗)或異常，要么在本地執(zhí)行事務(wù)等等，但不Commoit，處于Ready狀態(tài)。

提交階段：如果事務(wù)管理器收到了資源管理器的失敗信息(如異常、超時(shí)等)，直接給每個(gè)資源管理器發(fā)送回滾(Rollback)消息;否則，發(fā)送提交(Commit)消息;資源管理器根據(jù)事務(wù)管理器的指令執(zhí)行Commit或者Rollback操作，釋放所有事務(wù)處理過程中使用的鎖資源。(注意:必須在最后階段釋放鎖資源)

可以看出，二階段提交這么做的就是讓前面都完成了準(zhǔn)備工作，才能提交整個(gè)事務(wù)，若中間由某一環(huán)節(jié)出現(xiàn)問題，則整個(gè)事務(wù)回滾。

從兩階段提交的工作方式來看，很顯然，在提交事務(wù)的過程中需要在多個(gè)節(jié)點(diǎn)之間進(jìn)行協(xié)調(diào)，而各節(jié)點(diǎn)對(duì)鎖資源的釋放必須等到事務(wù)最終提交時(shí)，這樣，比起一階段提交，兩階段提交在執(zhí)行同樣的事務(wù)時(shí)會(huì)消耗更多時(shí)間。事務(wù)執(zhí)行時(shí)間的延長意味著鎖資源發(fā)生沖突的概率增加，當(dāng)事務(wù)的并發(fā)量達(dá)到一定數(shù)量的時(shí)候，就會(huì)出現(xiàn)大量事務(wù)積壓甚至出現(xiàn)死鎖，系統(tǒng)性能就會(huì)嚴(yán)重下滑。

MQ模型

消息一致性方案是通過消息中間件保證上下游應(yīng)用數(shù)據(jù)操作的一致性。基本思路是將本地操作和發(fā)送消息放在一個(gè)事務(wù)中，下游應(yīng)用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應(yīng)操作。本質(zhì)上是依靠消息的重試機(jī)制，達(dá)到最終一致性。消息驅(qū)動(dòng)的缺點(diǎn)是：耦合度高，需要在業(yè)務(wù)系統(tǒng)中引入MQ，導(dǎo)致系統(tǒng)復(fù)雜度增加。

bed模型(柔性事務(wù))

柔性事務(wù)是對(duì)XA協(xié)議的妥協(xié)和補(bǔ)償，它通過對(duì)強(qiáng)一致性要求的降低，已達(dá)到降低數(shù)據(jù)庫資源鎖定時(shí)間的效果。柔性事務(wù)的種類很多，可以通過各種不同的策略來權(quán)衡使用。

一階段提交 + 補(bǔ)償 ：最大努力送達(dá)(BED)

最大努力送達(dá)，是針對(duì)于弱XA的一種補(bǔ)償策略。它采用事務(wù)表記錄所有的事務(wù)操作SQL，如果子事務(wù)提交成功，將會(huì)刪除事務(wù)日志;如果執(zhí)行失敗，則會(huì)按照配置的重試次數(shù)，嘗試再次提交，即最大努力的進(jìn)行提交，盡量保證數(shù)據(jù)的一致性，這里可以根據(jù)不同的業(yè)務(wù)場景，平衡C和A，采用同步重試或異步重試。

這種策略的優(yōu)點(diǎn)是無鎖定資源時(shí)間，性能損耗小。缺點(diǎn)是嘗試多次提交失敗后，無法回滾，它僅適用于事務(wù)最終一定能夠成功的業(yè)務(wù)場景。因此BED是通過事務(wù)回滾功能上的妥協(xié)，來換取性能的提升。

sagas事務(wù)模型

Saga事務(wù)模型又叫做長時(shí)間運(yùn)行的事務(wù)(Long-running-transaction), 它是由普林斯頓大學(xué)的H.Garcia-Molina等人提出，它描述的是另外一種在沒有兩階段提交的的情況下解決分布式系統(tǒng)中復(fù)雜的業(yè)務(wù)事務(wù)問題。你可以在這里看到 Sagas 相關(guān)論文。

我們這里說的是一種基于 Sagas 機(jī)制的工作流事務(wù)模型，這個(gè)模型的相關(guān)理論目前來說還是比較新的，以至于百度上幾乎沒有什么相關(guān)資料。

該模型其核心思想就是拆分分布式系統(tǒng)中的長事務(wù)為多個(gè)短事務(wù)，或者叫多個(gè)本地事務(wù)，然后由 Sagas 工作流引擎負(fù)責(zé)協(xié)調(diào)，如果整個(gè)流程正常結(jié)束，那么就算是業(yè)務(wù)成功完成，如果在這過程中實(shí)現(xiàn)失敗，那么Sagas工作流引擎就會(huì)以相反的順序調(diào)用補(bǔ)償操作，重新進(jìn)行業(yè)務(wù)回滾。

比如我們一次關(guān)于購買旅游套餐業(yè)務(wù)操作涉及到三個(gè)操作，他們分別是預(yù)定車輛，預(yù)定賓館，預(yù)定機(jī)票，他們分別屬于三個(gè)不同的遠(yuǎn)程接口。可能從我們程序的角度來說他們不屬于一個(gè)事務(wù)，但是從業(yè)務(wù)角度來說是屬于同一個(gè)事務(wù)的。

他們的執(zhí)行順序如上圖所示，所以當(dāng)發(fā)生失敗時(shí)，會(huì)依次進(jìn)行取消的補(bǔ)償操作。

因?yàn)殚L事務(wù)被拆分了很多個(gè)業(yè)務(wù)流，所以 Sagas 事務(wù)模型最重要的一個(gè)部件就是工作流或者你也可以叫流程管理器(Process Manager)，工作流引擎和Process Manager雖然不是同一個(gè)東西，但是在這里，他們的職責(zé)是相同的。在選擇工作流引擎之后，最終的代碼也許看起來是這樣的。如果大家想了解更多相關(guān)知識(shí)，可以關(guān)注一下動(dòng)力節(jié)點(diǎn)的Dubbo教程，里面的內(nèi)容細(xì)致全面，通俗易懂，適合小白學(xué)習(xí)，希望對(duì)大家能夠有所幫助。