1.優先使用非同步訊息。

上文已經說過，使用非同步訊息 Consumer 端需要實現冪等。
冪等有兩種方式，一種方式是業務邏輯保證冪等。比如接到支付成功的訊息訂單狀態變成支付完成，如果當前狀態是支付完成，則再收到一個支付成功的訊息則說明訊息重複了，直接作為訊息成功處理。

另外一種方式如果業務邏輯無法保證冪等，則要增加一個去重表或者類似的實現。對於 producer 端在業務資料庫的同例項上放一個訊息庫，發訊息和業務操作在同一個本地事務裡。發訊息的時候訊息並不立即發出，而是向訊息庫插入一條訊息記錄，然後在事務提交的時候再非同步將訊息發出，傳送訊息如果成功則將訊息庫裡的訊息刪除，如果遇到訊息佇列服務異常或網路問題，訊息沒有成功發出那麼訊息就留在這裡了，會有另外一個服務不斷地將這些訊息掃出重新發送。

2.使用事務記錄庫

2.有的業務不適合非同步訊息的方式，事務的各個參與方都需要同步的得到結果。這種情況的實現方式其實和上面類似，每個參與方的本地業務庫的同例項上面放一個事務記錄庫。

比如 A 同步呼叫 B，C。A 本地事務成功的時候更新本地事務記錄狀態，B 和 C 同樣。如果有一次 A 呼叫 B 失敗了，這個失敗可能是 B 真的失敗了，也可能是呼叫超時，實際 B 成功。則由一箇中心服務對比三方的事務記錄表，做一個最終決定。假設現在三方的事務記錄是 A 成功，B 失敗，C 成功。那麼最終決定有兩種方式，根據具體場景：

1. 重試 B，直到 B 成功，事務記錄表裡記錄了各項呼叫引數等資訊

對 b 場景做一個特殊說明：比如 B 是扣庫存服務，在第一次呼叫的時候因為某種原因失敗了，但是重試的時候庫存已經變為 0，無法重試成功，這個時候只有回滾 A 和 C 了。

那麼可能有人覺得在業務庫的同例項裡放訊息庫或事務記錄庫，會對業務侵入，業務還要關心這個庫，是否一個合理的設計？

實際上可以依靠運維的手段來簡化開發的侵入，我們的方法是讓 DBA 在公司所有 MySQL 例項上預初始化這個庫，通過框架層（訊息的客戶端或事務 RPC 框架）透明的在背後操作這個庫，業務開發人員只需要關心自己的業務邏輯，不需要直接訪問這個庫。

總結起來，其實兩種方式的根本原理是類似的，

我們在交易建立流程中，首先建立一個不可見訂單，然後在同步呼叫鎖券和扣減庫存時，針對呼叫異常（失敗或者超時），發出廢單訊息到MQ。如果訊息傳送失敗，本地會做時間階梯式的非同步重試；優惠券系統和庫存系統收到訊息後，會進行判斷是否需要做業務回滾，這樣就準實時地保證了多個本地事務的最終一致性。

業務與訊息解耦方式

上述儲存訊息的方式使得訊息資料和業務資料緊耦合在一起，從架構上看不夠優雅，而且容易誘發其他問題。為了解耦，可以採用以下方式。

1）支付寶在扣款事務提交之前，向實時訊息服務請求傳送訊息，實時訊息服務只記錄訊息資料，而不真正傳送，只有訊息傳送成功後才會提交事務；

2）當支付寶扣款事務被提交成功後，向實時訊息服務確認傳送。只有在得到確認傳送指令後，實時訊息服務才真正傳送該訊息；

3）當支付寶扣款事務提交失敗回滾後，向實時訊息服務取消傳送。在得到取消傳送指令後，該訊息將不會被髮送；

4）對於那些未確認的訊息或者取消的訊息，需要有一個訊息狀態確認系統定時去支付寶系統查詢這個訊息的狀態並進行更新。為什麼需要這一步驟，舉個例子：假設在第2步支付寶扣款事務被成功提交後，系統掛了，此時訊息狀態並未被更新為“確認傳送”，從而導致訊息不能被髮送。

優點：訊息資料獨立儲存，降低業務系統與訊息系統間的耦合；

缺點：一次訊息傳送需要兩次請求；業務處理服務需要實現訊息狀態回查介面。

如何解決訊息重複投遞的問題

還有一個很嚴重的問題就是訊息重複投遞，以我們支付寶轉賬到餘額寶為例，如果相同的訊息被重複投遞兩次，那麼我們餘額寶賬戶將會增加2萬而不是1萬了。

為什麼相同的訊息會被重複投遞？比如餘額寶處理完訊息msg後，傳送了處理成功的訊息給支付寶，正常情況下支付寶應該要刪除訊息msg，但如果支付寶這時候悲劇的掛了，重啟後一看訊息msg還在，就會繼續傳送訊息msg。