SpringCloud微服務實戰(七)-訊息服務在電商中的實踐

摘要： 6 商品和訂單服務中使用MQ(上) 6.1 同步 原始流程-同步流程 在訂單生成的時候直接扣庫存，這是最初等的方式扣庫存，這種方式比較簡單，但是也有一系列的問題： 會造成有很多訂單把產品庫存扣除而並沒有支付，這...

6 商品和訂單服務中使用MQ(上)

6.1 同步

在訂單生成的時候直接扣庫存，這是最初等的方式扣庫存，這種方式比較簡單，但是也有一系列的問題：

• 會造成有很多訂單把產品庫存扣除而並沒有支付，這就需要有一個後臺指令碼，將一段時間內沒有支付的訂單的庫存釋放，把訂單取消掉
• 即時扣庫存，併發差

1,3商品服務,操作商品服務的 db

2,4 訂單服務.操作訂單服務的 db

6.2 改造成基於訊息佇列的非同步操作

首先考慮只將第四步非同步化

分析:2,4都是操作db,第四步不再等待,

1,2,3成功後即反饋給使用者

之後通過訊息通知服務非同步下單,若第4步非同步下單失敗了,傾向於重試操作,試圖重新生成訂單,訊息佇列的訊息也是可回溯的

訂單建立完成後,處於排隊狀態,然後服務釋出一個事件 Order Created 到訊息佇列中

即訂單服務向外界傳送訊息:我建立了一個訂單

由MQ 轉發給訂閱該訊息的服務

如果商品服務收到建立訂單訊息之後執行扣庫存操作

注意,這裡可能因為某些不可抗因素導致扣庫存失敗

無論成功與否,商品服務都會發送一個扣庫存訊息到 MQ 中,訊息內容即扣庫存的結果

訂單服務會訂閱扣庫存的結果,接收到該訊息後

已確認
已取消

欲實現上述模型要求,需要以下保證

服務發出的訊息,一定會被MQ收到

前端配合排隊中等介面

商品/訂單服務都變成非同步化,適合秒殺類場景,當流量不大時,並不太適合如此改造