前言

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

案例說明

以一個(gè)財(cái)務(wù)報(bào)賬業(yè)務(wù)為例，涉及到的系統(tǒng)如下：

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

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

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

當(dāng)審核人員審核通過時(shí)，大致流程如下：

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

代碼如下：

圖片

風(fēng)險(xiǎn)分析

圖片

如圖所示，如果在1和2出現(xiàn)異常，由于有事務(wù)的存在，操作1內(nèi)的幾條mysql寫操作會(huì)被回滾，因此所有數(shù)據(jù)都沒有任何變化。

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

對(duì)于用戶而言，他在頁(yè)面會(huì)收到報(bào)錯(cuò)，然后可能會(huì)再次點(diǎn)擊“審核通過”，而此時(shí)BPM那邊卻顯示，流程已經(jīng)走到下一個(gè)節(jié)點(diǎn)，該用戶無權(quán)限操作。

問題分析

根本原因其實(shí)不難，因?yàn)镸YSQL事務(wù)只能管他自己，沒法控制第三方系統(tǒng)。

解決思路

一個(gè)字：拆！

對(duì)于分布式系統(tǒng)，沒有任何人能保證遠(yuǎn)程調(diào)用不出問題，因此在做設(shè)計(jì)時(shí)，就必須能夠?qū)@種情況做出應(yīng)對(duì)。

上面的操作，打包放進(jìn)一個(gè)大事務(wù)就是根因，因此方案就是將大事務(wù)拆開，在拆分時(shí)，需要遵循以下幾個(gè)原則：

• 小事務(wù)內(nèi)，盡量只有一個(gè)遠(yuǎn)程寫操作
• 該遠(yuǎn)程寫操作放到方法最后，保證在其返回成功后就能立刻提交事務(wù)
• 小事務(wù)可能會(huì)因?yàn)槟承┰蚴?，因此需要機(jī)制來進(jìn)行重試

整體思路就是這樣：

圖片

基于以上原則，改動(dòng)如下：

第一步，新建一張任務(wù)表：

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

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

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

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

掃描任務(wù)

圖片

執(zhí)行任務(wù)

這是一個(gè)策略模式接口，每個(gè)小事務(wù)就封裝一個(gè)獨(dú)立的實(shí)現(xiàn)類。

圖片

其中更新待審人的任務(wù)實(shí)現(xiàn)如下，其實(shí)就是把那部分代碼復(fù)制過來。

圖片

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

圖片

其中步驟2（插入任務(wù)數(shù)據(jù)的代碼）的具體實(shí)現(xiàn)如下(transactionJobService.create)。

圖片

優(yōu)化

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

圖片

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

圖片

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

注意

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

結(jié)語

目前只給出了解決思路的核心，但真實(shí)項(xiàng)目中，還添加了不少額外功能，以后會(huì)逐漸更新進(jìn)來。