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