前言
這篇文章是《關於分布式事務的理解》的后續篇：分布式事務之最終一致性實現方案。
還是那個電商需求，一個訂單支付完成后的業務場景，有如下操作：
- 更改訂單的狀態為 “已支付”
- 扣減商品庫存
- 給會員增加積分
- 創建出庫單通知倉庫發貨
咱們使用 最終一致性方案 去實現它。
什么是最終一致性？
從字面上看就是 保證數據最后的一致性 就可以了。
為了減少系統代價，如果中間節點處理失敗，其他節點一般不會自動回滾，而是通過重試機制和人工參與的方式對失敗數據進行處理，從而來保證數據最后的一致性。
實現方案
使用 本地消息表 + 后台任務 + 消息隊列 + 接口冪等性。
本地消息表：在對應業務數據庫中增加的本地消息表，這張表存儲業務產生的消息，通過 本地事務 保證業務數據和消息數據的一致性，比如：msg_published 和 msg_received 表示發布消息表和接收消息表，在消息表中會有一個狀態來標識業務是否執行成功。
后台任務：當消息表中有執行失敗的業務信息時，后台任務就會按照配置的重試策略進行重試，例如重試策略為當發送和消費消息的過程中失敗會立即重試 3 次，在 3 次以后將進入重試輪詢；重試將在發送和消費消息失敗的 4分鍾后 開始，這是為了避免設置消息狀態延遲導致可能出現的問題；后續就會每隔 1 分鍾之后重試一次，默認的最高重試次數為 50 次，當達到 50 次時，就不會重試了，通過發郵件/微信/釘釘/短信的方式通知人工去處理，通知時需要考慮消息降噪。
消息隊列：跨服務之間的調用使用消息隊列，來實現服務解耦。
接口冪等性：接口需要保證同一操作發起的一次請求或者多次請求的結果必須是一致的。
代碼實現
推薦一個 C# 開源項目 CAP，大家可以參考一下。
這個項目只支持 C# 代碼去集成，如果是其他語言可以參考其設計思路，然后進行一個簡單的實現。
小結
本文純屬拋磚引玉，有問題，歡迎批評指正。
你有更好的實現方案嗎？歡迎留言~