最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務，適用于一些最終一致性時間敏感度低的業務，且被動方處理結果不影響主動方的處理結果，典型的使用場景：如銀行通知、商戶通知等，
最大努力通知
最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務，適用于一些最終一致性時間敏感度低的業務，且被動方處理結果 不影響主動方的處理結果，典型的使用場景：如銀行通知、商戶通知等，最大努力通知型的實作方案，一般符合以下特點：
- 不可靠訊息：業務活動主動方，在完成業務處理之后，向業務活動的被動方發送訊息，直到通知N次后不再通知，允許訊息丟失(不可靠訊息)，
- 定期校對：業務活動的被動方，根據定時策略，向業務活動主動方查詢(主動方提供查詢介面)，恢復丟失的業務訊息，
最大努力通知示例
舉例來說：筆者曾經做過一個短信發送平臺，背景是公司內部有多個業務都有發送短信的需求，如果每個業務獨立實作短信發送功能，存在功能實作上的重復，因此專門做了一個短信平臺專案，所有的業務方都接入這個短信平臺，來實作發送短信的功能，簡化后的架構如下所示：
短信發送流程
業務方發送一次短信的流程包含如下步驟：
- 業務方將短信發送請求提交給短信平臺；
- 短信平臺接收到要發送的短信，記錄到資料庫中，并標記其狀態為”已接收"；
- 短信平臺呼叫外部短信發送供應商的介面，發送短信，外部供應商的介面也是異步將短信發送到用戶手機上，因此這個介面呼叫后，立即回傳，進入第4步；
- 更新短信發送狀態為"已發送"；
- 短信發送供應商異步通知短信平臺短信發送結果，而通知可能失敗，因此最多只會通知N次，；
- 短信平臺接收到短信發送結果后，更新短信發送狀態，可能是成功，也可能失敗(如手機欠費)，到底是成功還是失敗并不重要，重要的是我們知道了這調短信發送的最終結果；
- 如果最多只通知N次，如果都失敗了的話，那么短信平臺將不知道短信到底有沒有成功發送，因此短信發送供應商需要提供一個查詢介面，以方便短信平臺驅動的去查詢，進行定期校對，
在這個案例中，短信發送供應商通知短信平臺短信發送結果的程序中，就是最典型的最大努力通知型方案，通知了N次就不再通知，通過提供一個短信結果查詢介面，讓短信平臺可以進行定期的校對，而由于短信發送業務的時間敏感度并不高，比較適合采用這個方案，
需要注意的是，短信結果查詢介面很重要，必須要進行定期校對，因為后期要進行對賬，筆者在做這個專案的時候，一個月的短信發送總量在高峰期可以達到1億條左右，即使一條短信只要5分錢，一個月就有500W，
參考檔案
柔性事務：最大努力通知
本文最先發布至微信公眾號，著作權所有，禁止轉載！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/354452.html
標籤：其他
上一篇：SpringBoot 中發布ApplicationEventPublisher，監聽ApplicationEvent 異步操作
下一篇：《我是廖志偉》