分佈式事務之最終一致性實現方案

文章目錄：

前言

這篇文章是《關於分佈式事務的理解》的後續篇：分佈式事務之最終一致性實現方案。

還是那個電商需求，一個訂單支付完成後的業務場景，有如下操作：

  1. 更改訂單的狀態爲 “已支付”

  2. 扣減商品庫存

  3. 給會員增加積分

  4. 創建出庫單通知倉庫發貨

咱們使用 最終一致性方案 去實現它。

什麼是最終一致性？

從字面上看就是 保證數據最後的一致性 就可以了。

爲了減少系統代價，如果中間節點處理失敗，其他節點一般不會自動回滾，而是通過重試機制和人工參與的方式對失敗數據進行處理，從而來保證數據最後的一致性。

實現方案

使用 本地消息表 + 後臺任務 + 消息隊列 + 接口冪等性。

本地消息表：在對應業務數據庫中增加的本地消息表，這張表存儲業務產生的消息，通過 本地事務 保證業務數據和消息數據的一致性，比如：msg_published 和 msg_received 表示發佈消息表和接收消息表，在消息表中會有一個狀態來標識業務是否執行成功。

後臺任務：當消息表中有執行失敗的業務信息時，後臺任務就會按照配置的重試策略進行重試，例如重試策略爲當發送和消費消息的過程中失敗會立即重試 3 次，在 3 次以後將進入重試輪詢；重試將在發送和消費消息失敗的 4 分鐘後 開始，這是爲了避免設置消息狀態延遲導致可能出現的問題；後續就會每隔 1 分鐘之後重試一次，默認的最高重試次數爲 50 次，當達到 50 次時，就不會重試了，通過發郵件 / 微信 / 釘釘 / 短信的方式通知人工去處理，通知時需要考慮消息降噪。

消息隊列：跨服務之間的調用使用消息隊列，來實現服務解耦。

接口冪等性：接口需要保證同一操作發起的一次請求或者多次請求的結果必須是一致的。

代碼實現

推薦一個 C# 開源項目 CAP[1]，大家可以參考一下。

這個項目只支持 C# 代碼去集成，如果是其他語言可以參考其設計思路，然後進行一個簡單的實現。

小結

本文純屬拋磚引玉，有問題，歡迎批評指正。

你有更好的實現方案嗎？歡迎留言~

參考資料

[1]

CAP: https://github.com/dotnetcore/CAP

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/icVCxJ4n2lUQ30yOGYtADg

猜你喜歡