分佈式事務（五）之最大努力通知
最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務，適用於一些最終一致性時間敏感度低的業務，且被動方處理結果不影響主動方的處理結果。典型的使用場景：如銀行通知、商戶通知等。
最大努力通知
最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務，適用於一些最終一致性時間敏感度低的業務，且被動方處理結果 不影響主動方的處理結果。典型的使用場景：如銀行通知、商戶通知等。最大努力通知型的實現方案，一般符合以下特點：
- 不可靠消息：業務活動主動方，在完成業務處理之後，向業務活動的被動方發送消息，直到通知N次後不再通知，允許消息丟失(不可靠消息)。
- 定期校對：業務活動的被動方，根據定時策略，向業務活動主動方查詢(主動方提供查詢接口)，恢復丟失的業務消息。
最大努力通知示例
舉例來說：筆者曾經做過一個短訊發送平台，背景是公司內部有多個業務都有發送短訊的需求，如果每個業務獨立實現短訊發送功能，存在功能實現上的重複。因此專門做了一個短訊平台項目，所有的業務方都接入這個短訊平台，來實現發送短訊的功能。簡化後的架構如下所示：
短訊發送流程
業務方發送一次短訊的流程包含如下步驟：
- 業務方將短訊發送請求提交給短訊平台；
- 短訊平台接收到要發送的短訊，記錄到數據庫中，並標記其狀態為」已接收”；
- 短訊平台調用外部短訊發送供應商的接口，發送短訊。外部供應商的接口也是異步將短訊發送到用戶手機上，因此這個接口調用後，立即返回，進入第4步；
- 更新短訊發送狀態為”已發送”；
- 短訊發送供應商異步通知短訊平台短訊發送結果。而通知可能失敗，因此最多只會通知N次。；
- 短訊平台接收到短訊發送結果後，更新短訊發送狀態，可能是成功，也可能失敗(如手機欠費)。到底是成功還是失敗並不重要，重要的是我們知道了這調短訊發送的最終結果；
- 如果最多只通知N次，如果都失敗了的話，那麼短訊平台將不知道短訊到底有沒有成功發送。因此短訊發送供應商需要提供一個查詢接口，以方便短訊平台驅動的去查詢，進行定期校對。
在這個案例中，短訊發送供應商通知短訊平台短訊發送結果的過程中，就是最典型的最大努力通知型方案，通知了N次就不再通知。通過提供一個短訊結果查詢接口，讓短訊平台可以進行定期的校對。而由於短訊發送業務的時間敏感度並不高，比較適合採用這個方案。
需要注意的是，短訊結果查詢接口很重要，必須要進行定期校對。因為後期要進行對賬，筆者在做這個項目的時候，一個月的短訊發送總量在高峰期可以達到1億條左右，即使一條短訊只要5分錢，一個月就有500W。
參考文檔
本文最先發佈至微信公眾號，版權所有，禁止轉載！
