分布式事務（五）之最大努力通知

最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務，適用於一些最終一致性時間敏感度低的業務，且被動方處理結果不影響主動方的處理結果。典型的使用場景：如銀行通知、商戶通知等。

最大努力通知

最大努力通知型( Best-effort delivery)是最簡單的一種柔性事務，適用於一些最終一致性時間敏感度低的業務，且被動方處理結果 不影響主動方的處理結果。典型的使用場景：如銀行通知、商戶通知等。最大努力通知型的實現方案，一般符合以下特點：

1. 不可靠消息：業務活動主動方，在完成業務處理之后，向業務活動的被動方發送消息，直到通知N次后不再通知，允許消息丟失(不可靠消息)。
2. 定期校對：業務活動的被動方，根據定時策略，向業務活動主動方查詢(主動方提供查詢接口)，恢復丟失的業務消息。

最大努力通知示例

舉例來說：筆者曾經做過一個短信發送平台，背景是公司內部有多個業務都有發送短信的需求，如果每個業務獨立實現短信發送功能，存在功能實現上的重復。因此專門做了一個短信平台項目，所有的業務方都接入這個短信平台，來實現發送短信的功能。簡化后的架構如下所示：

短信發送流程

業務方發送一次短信的流程包含如下步驟：

1. 業務方將短信發送請求提交給短信平台；
2. 短信平台接收到要發送的短信，記錄到數據庫中，並標記其狀態為”已接收"；
3. 短信平台調用外部短信發送供應商的接口，發送短信。外部供應商的接口也是異步將短信發送到用戶手機上，因此這個接口調用后，立即返回，進入第4步；
4. 更新短信發送狀態為"已發送"；
5. 短信發送供應商異步通知短信平台短信發送結果。而通知可能失敗，因此最多只會通知N次。；
6. 短信平台接收到短信發送結果后，更新短信發送狀態，可能是成功，也可能失敗(如手機欠費)。到底是成功還是失敗並不重要，重要的是我們知道了這調短信發送的最終結果；
7. 如果最多只通知N次，如果都失敗了的話，那么短信平台將不知道短信到底有沒有成功發送。因此短信發送供應商需要提供一個查詢接口，以方便短信平台驅動的去查詢，進行定期校對。

在這個案例中，短信發送供應商通知短信平台短信發送結果的過程中，就是最典型的最大努力通知型方案，通知了N次就不再通知。通過提供一個短信結果查詢接口，讓短信平台可以進行定期的校對。而由於短信發送業務的時間敏感度並不高，比較適合采用這個方案。

需要注意的是，短信結果查詢接口很重要，必須要進行定期校對。因為后期要進行對賬，筆者在做這個項目的時候，一個月的短信發送總量在高峰期可以達到1億條左右，即使一條短信只要5分錢，一個月就有500W。

參考文檔

柔性事務：最大努力通知

本文最先發布至微信公眾號，版權所有，禁止轉載！