1 背景

市面上常見的有，2pc/3pc、tcc、saga 等常見的分布式事務(wù)解決方案，但是實際實施起來框架比較重，設(shè)計開發(fā)比較繁瑣，不易于快速開發(fā)上手。本文提供一種基于柔性事務(wù)設(shè)計的簡單易上手的分布式事務(wù)設(shè)計方案，用于解決常見的分布式事務(wù)常見場景。

2 常見分布式事務(wù)場景

2.1 同步場景

常見的場景，方法內(nèi)依賴外部微服務(wù)多個同步接口，等同步接口返回再展開后續(xù)邏輯，如下圖 1 描述。

圖 1 分布式事務(wù)同步場景 存在的問題：B/C 失敗后，A/B 不能回滾，造成數(shù)據(jù)不一致？

2.2 異步場景

方法內(nèi)依賴外部微服務(wù)多個同步接口同時，本地事務(wù)提交并發(fā)出異步 MQ，如下圖 2 描述。

圖 2 分布式事務(wù)異步場景 存在的問題：詢價系統(tǒng)無法保證本地事務(wù)和 mq 消息的發(fā)送同時成功或失敗，會造成數(shù)據(jù)不一致。

3 解決方案

3.1 數(shù)據(jù)模型設(shè)計

事務(wù)表：記錄每次同步方法執(zhí)行的狀態(tài)，包括：1 - 進行中（同步方法執(zhí)行開始）、2 - 已完成（同步方法執(zhí)行成功）、3 - 失?。ㄍ椒椒▓?zhí)行失?。? - 已回滾（回滾方法執(zhí)行成功）； 方法調(diào)用表：記錄一個完整的事務(wù)內(nèi)所有方法的執(zhí)行前入?yún)?、同步方?a target="_blank">接口、回滾接口、回滾入?yún)?、方法?zhí)行順序，如下圖 3 描述：

圖 3 事務(wù)服務(wù)數(shù)據(jù)模型

3.2 設(shè)計原理

原理：一個完整事務(wù)內(nèi)，1. 首先每個方法提供回滾接口，其次，事務(wù)內(nèi)每次同步方法執(zhí)行時，優(yōu)先維護入?yún)?shù)據(jù)到事務(wù)表，方便后續(xù)做回滾補償；2. 整個事務(wù)內(nèi)某一個方法執(zhí)行失敗時，結(jié)束整個事務(wù)，并更新事務(wù)表狀態(tài) = 失敗；3. 事務(wù)表通過輪詢狀態(tài) status=3 (失敗) 事務(wù)，調(diào)用回滾接口，利用回滾入?yún)⑦M行接口補償；4. 回滾邏輯：找到事務(wù)表中失敗的執(zhí)行方法的順序值，只調(diào)用小于失敗順序值的所有回滾接口、入?yún)?，注意并不回滾失敗值的接口，并根據(jù)順序倒序進行接口回滾補償。

圖 4 回滾原理圖

3.3 執(zhí)行時序

圖 5 回滾執(zhí)行時序圖

3.4 回滾失敗處理方案：

事務(wù)服務(wù)的高可用保障：柔性事務(wù)前提是保證事務(wù)服務(wù)高可用性，重點保障；

回滾服務(wù)重試機制：回滾接口失敗重試機制，保證數(shù)據(jù)一致性；

為了避免架構(gòu)復(fù)雜度，做日志記錄、報警、人工處理。

4 注意問題

回滾服務(wù)的冪等性：回滾做好業(yè)務(wù)防重和系統(tǒng)防重，防止因為回滾帶來的業(yè)務(wù)數(shù)據(jù)不一致；

臟數(shù)據(jù)：整個事務(wù)中某一方法執(zhí)行失敗，前面調(diào)用方法的數(shù)據(jù)作為臟數(shù)據(jù)使用。簡單的解決方案：依賴事務(wù)表整個事務(wù)執(zhí)行狀態(tài)來決定能否使用臟數(shù)據(jù)。但缺點就是這樣會耦合業(yè)務(wù)邏輯；

中心化：整個事務(wù)的維護完全依賴事務(wù)服務(wù)完成，需要保證事務(wù)服務(wù)的高可用性；

實時性：事務(wù)維護本方案通過定時任務(wù)維護，如果業(yè)務(wù)場景有實時性要求，方式可以改為：在整個事務(wù)中某一方法執(zhí)行失敗時，catch 異常，catch 內(nèi)更新任務(wù)狀態(tài)成功時，直接進行回滾邏輯調(diào)用。

5 總結(jié)

除了通過常規(guī)本地大事務(wù)保證事務(wù)完整性方案，本次方案提供了一套基于柔性事務(wù)回滾補償?shù)姆绞絹肀ＷC分布式事務(wù)，通過維護事務(wù)服務(wù)和事務(wù)服務(wù)中心對應(yīng)數(shù)據(jù)表，從而保障整個分布式事務(wù)的完整性。實現(xiàn)方式簡單、輕量、易于操作，方便地解決了常見分布式事務(wù)場景。

編輯：黃飛

?