一、概述
咱們今天聊聊分布式事務系列中的最後一個方案：最大努力通知事務。最大努力通知事務的主流實作仍是基于MQ來進行事務控制。最大努力通知事務和事務消息都是通知型事務，主要适用于那些需要異步更新資料，并且對資料的實時性要求較低的場景。
最大努力通知事務主要用于外部系統，因為外部的網絡環境更加複雜和不可信，是以隻能盡最大努力去通知實作資料最終一緻性，比如充值平台與營運商、支付對接、商戶通知等等跨平台、跨企業的系統間業務互動場景；而事務消息主要适用于内部系統的資料最終一緻性保障，因為内部相對比較可控，比如訂單和購物車、收貨與清算、支付與結算等等場景。
普通消息是無法解決本地事務執行和消息發送的一緻性問題的。因為消息發送是一個網絡通信的過程，發送消息的過程就有可能出現發送失敗、或者逾時的情況。逾時有可能發送成功了，有可能發送失敗了，消息的發送方是無法确定的，是以此時消息發送方無論是送出事務還是復原事務，都有可能不一緻性出現。是以通知型事務的難度在于投遞消息和參與者自身本地事務的一緻性保障。
因為核心要點一緻，都是為了保證消息的一緻性投遞，是以最大努力通知事務在投遞流程上跟事務消息是一樣的，是以也有兩個分支：
l 基于MQ自身的事務消息方案
l 基于DB的本地事務消息表方案
二、最大努力通知事務流程
我們先看看事務消息的兩個分支：
圖表 1-基于MQ的事務消息
圖表 2-基于DB消息表的事務消息
最大努力通知事務在投遞之前跟上面流程都差不多，關鍵在于投遞後的處理，因為事務消息在于内部的事務處理，是以MQ和系統是直連并且無需嚴格的權限、安全等方面的思路設計。
圖表 3-基于事務消息的最大努力通知事務
圖表 4-基于DB消息表的最大努力通知事務
最大努力通知事務在投遞之前跟上面流程都差不多，關鍵在于投遞後的處理，因為事務消息在于内部的事務處理，是以MQ和系統是直連并且無需嚴格的權限、安全等方面的思路設計。最大努力通知事務在于第三方系統的對接，是以最大努力通知事務有幾個特性
• 業務主動方在完成業務處理後，向業務被動方(第三方系統)發送通知消息，允許存在消息丢失。
• 業務主動方提供遞增多擋位時間間隔(5min、10min、30min、1h、24h)，用于失敗重試調用業務被動方的接口；在通知N次之後就不再通知，報警+記日志+人工介入。
• 業務被動方提供幂等的服務接口，防止通知重複消費。
• 業務主動方需要有定期校驗機制，對業務資料進行兜底；防止業務被動方無法履行責任時進行業務復原，確定資料最終一緻性。
在很多其他資料都會說“業務被動方根據定時政策，向業務活動的主動方進行輪詢，進而恢複丢失的業務消息”；但在真實場景中被動方很多時候可能是業務強勢方，不會反向調用 業務主動方的接口；是以我們需要一定的熔斷探活機制來保證我們的通知有效性。還有很多資料也說“被動方的處理結果不影響主動方的處理結果”，在我的認知中，這句話其實是有缺陷的：在大多數下确實業務被動方的處理結果不影響業務主動方，但在業務被動方确定無法履行業務責任時，業務主動方可能仍需要復原業務資料。
三、最大努力通知事務 VS 事務消息
最大女郎通知事務在我認知中，其實是基于事務消息發展而來适用于外部對接的一種業務實作。他們主要有的是業務差别，如下：
• 從參與者來說：最大努力通知事務适用于跨平台、跨企業的系統間業務互動；事務消息更适用于同網絡體系的内部服務傳遞。
• 從消息層面說：最大努力通知事務需要主動推送并提供多檔次時間的重試機制來保證資料的通知；而事務消息隻需要消息消費者主動去消費。
• 從資料層面說：最大努力通知事務還需額外的定期校驗機制對資料進行兜底，保證資料的最終一緻性；而事務消息秩序保證消息的可靠投遞即可，自身無需對資料進行兜底處理。
四、總結
最大努力通知事務本質是通過引入定期校驗機制來對最終一緻性做兜底，對業務侵入性較低；适合于對最終一緻性敏感度比較低、業務鍊路較短的場景。
本文來源于：奈學開發者社群