前言

我們在開發(fā)的過程中，如果一個業(yè)務操作需要本地寫MYSQL數據以及對第三方系統(tǒng)做寫操作，那么這種流程就涉及到分布式系統(tǒng)一致性的問題，然而并非所有系統(tǒng)都能使用成熟的分布式事務方案。

案例說明

以一個財務報賬業(yè)務為例，涉及到的系統(tǒng)如下：

詳細解釋下各系統(tǒng)作用：

• 單據系統(tǒng)：財務報賬，會提交很多信息（例如：報賬事由、報賬金額與明細）。同時也會生成財務憑證（不了解憑證也沒關系，它就是給財務人員看的東西，對技術人員來說就是數據庫的一堆數據）。
• BPM系統(tǒng)：非常成熟的流程管理系統(tǒng)，以非常直觀的方式來實現流程的搭配，不了解的可以自行百度掃盲。在此案例中，需要使用BPM的兩個能力：1）調用API，審核通過 2）調用API，獲取流程的待審人。
• SAP系統(tǒng)：財務專用系統(tǒng)，不用過多了解，只要知道在財務審核完成后，會將單據系統(tǒng)生成的憑證數據通過API調用的方式發(fā)送給SAP即可。

“審核通過”業(yè)務流程

當審核人員審核通過時，大致流程如下：

• 保存業(yè)務數據+記錄審核日志
• 調用BPM接口，審核通過
• 調用BPM接口，獲取最新待審人
• 如果沒有待審人，說明已經審完，生成憑證并推送SAP

代碼如下：

圖片

風險分析

圖片

如圖所示，如果在1和2出現異常，由于有事務的存在，操作1內的幾條mysql寫操作會被回滾，因此所有數據都沒有任何變化。

但如果1和2正常執(zhí)行，操作3發(fā)生異常，操作1的數據會因為事務回滾，但操作2并不能。因此整個系統(tǒng)會出現一個很詭異的現象：單據系統(tǒng)內，沒有任何日志記錄，用戶操作的數據也沒有保留下來，但BPM那邊卻已經審核通過了，這在任何正常流程中，都是不可能出現的狀態(tài)。

對于用戶而言，他在頁面會收到報錯，然后可能會再次點擊“審核通過”，而此時BPM那邊卻顯示，流程已經走到下一個節(jié)點，該用戶無權限操作。

問題分析

根本原因其實不難，因為MYSQL事務只能管他自己，沒法控制第三方系統(tǒng)。

解決思路

一個字：拆！

對于分布式系統(tǒng)，沒有任何人能保證遠程調用不出問題，因此在做設計時，就必須能夠對這種情況做出應對。

上面的操作，打包放進一個大事務就是根因，因此方案就是將大事務拆開，在拆分時，需要遵循以下幾個原則：

• 小事務內，盡量只有一個遠程寫操作
• 該遠程寫操作放到方法最后，保證在其返回成功后就能立刻提交事務
• 小事務可能會因為某些原因失敗，因此需要機制來進行重試

整體思路就是這樣：

圖片

基于以上原則，改動如下：

第一步，新建一張任務表：

CREATE TABLE `transaction_job` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`type` varchar(255) NOT NULL COMMENT '任務類型',
`data` varchar(255) NOT NULL COMMENT '任務數據',
`error_message` varchar(255) DEFAULT NULL COMMENT '錯誤信息',
`context` varchar(255) DEFAULT NULL COMMENT '任務上下文（主要是保存當前操作人）',
`create_time` bigint(20) NOT NULL COMMENT '創(chuàng)建時間',
`update_time` bigint(20) NOT NULL COMMENT '更新時間',
`retry_times` int(11) NOT NULL DEFAULT '0' COMMENT '重試次數',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='事務任務表';

作用：保存小事務的關鍵數據到data字段中，以保證通過該字段，就能正確執(zhí)行小事務。另外也需要保存當前操作人的信息context。

第二步，通過定時任務，查出transaction_job表中未完成的數據，并執(zhí)行對應的操作，這里通過簡單的策略模式，將框架代碼和業(yè)務代碼做了分離

首先是框架代碼核心邏輯。

掃描任務

圖片

執(zhí)行任務

這是一個策略模式接口，每個小事務就封裝一個獨立的實現類。

圖片

其中更新待審人的任務實現如下，其實就是把那部分代碼復制過來。

圖片

第三步，改造業(yè)務代碼，不再一次性把流程寫完，而且是在第一個小事務中，順便往transaction_job中插入一條數據，以執(zhí)行第二個小事務。

圖片

其中步驟2（插入任務數據的代碼）的具體實現如下(transactionJobService.create)。

圖片

優(yōu)化

上述方案種，除第一個事務外，后續(xù)事務都是通過定時任務來執(zhí)行的，因此這些事務都存在一定的延遲，用戶體驗不好，解決辦法也非常簡單，只需要利用好Spring對于事務的生命周期管理，稍微改造一下插入任務的方法（transactionJobService.create）。

圖片

這是Spring提供的工具類，afterCommit()方法會在事務提交后執(zhí)行，因此加上這段代碼后，思路就變成了這樣。

圖片

如果小事務順利執(zhí)行，會立刻將該任務改為“成功”，因此從用戶端是感受不到延遲的。

注意

可能存在添加任務后，定時任務也立刻掃描到了這條數據，同一任務就會被主線程與定時任務線程同時執(zhí)行，所以實際應用中需要考慮這個問題（比如：加鎖再執(zhí)行，執(zhí)行前再檢查數據庫狀態(tài)）。

結語

目前只給出了解決思路的核心，但真實項目中，還添加了不少額外功能，以后會逐漸更新進來。