背景
微服務場景下需要同步資訊的場景。
還是前文的栗子: 如下微服務
- 支付服務：負責完成支付操作，其中有支付流水資料。
- 賬單服務：指定時間生成賬單給使用者，其中有賬單流水資料。
此時產品上有個需求，在支付管理端根據是否出賬搜尋支付流水，而出賬是賬單服務的功能。所以這裡涉及到資訊的同步，那麼，我們怎麼保證同步一定能成功呢（最終一致性）。
消費者
保證在佇列中的訊息，一定會被消費。用白話來講，就是不停消費直到成功。
方式比較簡單： 訊息佇列都使用手動提交。處理完了，再保證提交。 儘量遵循觸發-查詢機制，提供可重入性，即訊息佇列只傳遞id這種非實質資訊，收到之後再通過rpc查詢拉取完整資料來更新。
生產者
主要是傳送訊息到佇列這步的可靠性考量
方案一：淺嘗輒止
以遞增的時間間隔重試5次。如果失敗了，上報到日誌和告警，人工介入。 同時，具體業務準備好重試的指令碼。根據實時的情況進行處理。 優點：
- 簡單，能解決瞬間的網路抖動造成的失敗。
缺點：
- 可靠性低。在訊息佇列故障30分鐘這種場景下，無法自動恢復，同時從日誌撈取資訊，也不是特別方便。
方案二：內有波瀾
失敗之後，記憶體維護一個重試佇列，先由5，10，20， 40， 80， 160， 320s的間隔重試。 之後以5分鐘一次的間隔請求。同時，也要打入日誌系統，告警通知。
優點：可靠性會比一高很多，在訊息佇列故障30分鐘這種場景下，也能自動恢復。可以做成package的方式，方便接入。
缺點：
- 服務重啟或者機器掛了，訊息就丟了。
限制：
- 訊息處理需要遵循觸發-查詢機制
方案三：內有波瀾plus
失敗之後，記憶體維護一個重試佇列，先由5，10，20， 40， 80，160， 320s的間隔重試。然後append到本地檔案，同時以5分鐘一次的頻率做重試。重試完成之後，從磁碟中刪除對應資訊。當服務重啟，從磁碟把資料匯入記憶體即可。
優點：
- 可靠性會比一高很多，在訊息佇列故障30分鐘這種場景下，也能自動恢復，可以做成包的方式。
- 具有比較強的通用型
缺點：
- 增加了和磁碟打交道的邏輯，引入了檔案io。
限制：
- 訊息處理需要遵循觸發-查詢機制
方案四：有備無患
實現任務重試微服務，該服務通過維護一張任務表，重試任務直到成功。相當於是訊息佇列這個可靠中介軟體有問題，就丟給這個重試服務這個自己實現的“中介軟體”。
優點：
- 可靠性會比一高很多，在訊息佇列故障30分鐘這種場景下，也能自動恢復。
- 具有比較強的通用性。
缺點：
- 成本變高，需要額外服務。同時，如果服務也掛了，還是得依賴上報。（當然，上報也可能掛了）
限制：
- 訊息處理需要遵循觸發-查詢機制
以上方案中，三，四基本能解決重試階段寫入訊息佇列的可靠性問題。 但針對另一個場景：正想寫本身服務就沒了的情況（比如oom導致服務被系統kill了） 還是不行。
方案五：先入為主
要做變更之前，先寫入到訊息同步微服務，告訴他要做什麼事（把什麼訊息放入訊息佇列），和流程最長執行時間，以及發給誰。該服務維護一張任務表，任務初始處於未啟用狀態。
等業務做完要同步的時候，再rpc請求觸發啟用。
任務管理微服務如果發現一個任務，超過最長執行時間沒有啟用。就說明啟用rpc失敗了，或者是服務崩潰，本身就沒做變更。此時，自動啟用即可。
優點：完全可靠（事務可能還是會失敗，可靠指資料一定最終一致）。
缺點：
- 開發成本比較大，同時會增加訊息呼叫。
- 增加一個節點，事務失敗得可能性更高。
限制：
- 訊息處理需要遵循觸發-查詢機制
總結
推薦：方案三
推薦理由： 成本不高，可靠性較強。可靠度99.99%。（此處不論程式碼本身bug）