參照事務的基本特性，分析基於消息系統模型之最大努力通知模型。
1.事務的特性
- A(Atomicity)：事務中的全部操作都是一個原子操作序列，要麼一起成功，要麼一起失敗。其中任何一個操作失敗，之前已經成功操作也會回滾到操作之前的狀態。
- C(Consistency)：事務的執行結果從一個狀態切換到另一個狀態，當事務完成後各操作結果的狀態都是操作成功的狀態或操作之前的狀態時，就可以說是滿足一致性。
- I(Isolation)：事務之間不會互相影響，各事務之間都有獨立完整的數據空間。
- D(Durability)：事務一旦提交，對數據的變更必須永久的保存下來，就算重啓也可以恢復。
2.最大努力通知型
- 特點：不同系統間的通信或消息中間件不保證消息的正確接收/投遞。
- 優點：
- 事務本身邏輯簡單、實現簡單。
- 因不需要保證消息的可靠，因此全流程幾乎不需要阻塞、確認等額外操作。
- 缺點：
- 爲了實現事務的一致性，必須另外實現一套獨立的可行的校對系統。
- 因極端情況下依賴重試邏輯達到最終一致性，因此適合對於時間敏感度較低的場景。
- 只支持純異步場景，無法處理同步的請求。(依賴額外的校對系統/重試/主動查詢機制)
3.基本模型
4.分析
- 爲什麼需要額外的校對系統？
- 如圖中第一步操作失敗。服務A事務已經執行，服務B並沒有執行事務。此時是不符合一致性原則的。因此需要一個額外的校對系統進行不斷的輪詢，補全事務流程或通知人工處理。
- 爲什麼需要主動查詢機制？
- 如圖中第二步操作失敗。服務A的事務已經執行，服務B並沒有執行事務。此時也不符合一致性原則。當然可以全部依賴校對系統進行校對。
- 第三步ack的時機
- ACK這個步驟是必須的，因爲ACK的步驟是停止消息系統重試步驟的重要依據之一。(另一種重試機制停止可以爲到達一個重試最大次數)
- 服務B接口的冪等性
- 因爲在第三步收到ACK之前，消息系統會默認消息丟失，不斷進行重試，因此服務必須實現冪等性。即多次調用和一次調用結果是相同的。實現方式可以通過一個唯一的事件ID或MessageID實現。
- 常見的實現場景
- 例如支付寶、微信等第三方支付的回調，前端用戶點擊下單後，後端生成第三方支付需要的訂單信息返回前端，前端喚醒第三方APP進行支付，支付完成後第三方支付會通過之前註冊好的回調，不斷的嘗試回調，直到我們某一次處理返回成功。該場景下一般後端也會執行一個主動查詢腳本作爲兜底方案。