文章目錄：
前言
什麼是最終一緻性？
實作方案
代碼實作
小結
推薦閱讀
這篇文章是《關于分布式事務的了解》的後續篇：分布式事務之最終一緻性實作方案。
還是那個電商需求，一個訂單支付完成後的業務場景，有如下操作：
更改訂單的狀态為 “已支付”
扣減商品庫存
給會員增加積分
建立出庫單通知倉庫發貨
咱們使用 最終一緻性方案 去實作它。
從字面上看就是 保證資料最後的一緻性 就可以了。
為了減少系統代價，如果中間節點處理失敗，其他節點一般不會自動復原，而是通過重試機制和人工參與的方式對失敗資料進行處理，進而來保證資料最後的一緻性。
使用 本地消息表 + 背景任務 + 消息隊列 + 接口幂等性。
本地消息表：在對應業務資料庫中增加的本地消息表，這張表存儲業務産生的消息，通過 本地事務 保證業務資料和消息資料的一緻性，比如：msg_published 和 msg_received 表示釋出消息表和接收消息表，在消息表中會有一個狀态來辨別業務是否執行成功。
背景任務：當消息表中有執行失敗的業務資訊時，背景任務就會按照配置的重試政策進行重試，例如重試政策為當發送和消費消息的過程中失敗會立即重試 3 次，在 3 次以後将進入重試輪詢；重試将在發送和消費消息失敗的 4分鐘後 開始，這是為了避免設定消息狀态延遲導緻可能出現的問題；後續就會每隔 1 分鐘之後重試一次，預設的最高重試次數為 50 次，當達到 50 次時，就不會重試了，通過發郵件/微信/釘釘/短信的方式通知人工去處理，通知時需要考慮消息降噪。
消息隊列：跨服務之間的調用使用消息隊列，來實作服務解耦。
接口幂等性：接口需要保證同一操作發起的一次請求或者多次請求的結果必須是一緻的。
推薦一個 C# 開源項目 CAP[1]，大家可以參考一下。
這個項目隻支援 C# 代碼去內建，如果是其他語言可以參考其設計思路，然後進行一個簡單的實作。
本文純屬抛磚引玉，有問題，歡迎批評指正。
你有更好的實作方案嗎？歡迎留言~
回答兩個被頻繁問到的代碼寫法問題
根據使用者回報，對開源項目 go-gin-api 新增兩個功能
關于處理電商系統訂單狀态的流轉，分享下我的技術方案（附帶源碼）
我是怎麼寫 Git Commit message 的？
[1]
CAP: https://github.com/dotnetcore/CAP