當商品和訂單服務間使用MQ
當商品服務的庫存變更時，透過MQ 通知訂單服務庫存變化。
原始的同步流程
- 查詢商品資訊(呼叫商品服務)
- 計算總價(產生訂單詳情)
- 商品服務扣庫存(呼叫商品服務)
- 訂單入庫( 產生訂單)
// 原始的MySQL同步流程// 判断此代金券是否加入抢购SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId);AssertUtil.isTrue(seckillVouchers == null, "该代金券并未有抢购活动");// 判断是否有效AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, "该活动已结束");// 插入数据库seckillVouchersMapper.save(seckillVouchers);
登入後複製
#推薦（免費）：redis
在訂單產生時直接扣庫存，這是最原始的扣庫存方案，比較簡單，但存在
問題
- #可能導致許多訂單把產品庫存扣除而未支付，這就需要有一個後台腳本，將一段時間內沒有支付的訂單的庫存釋放，把訂單取消
- 即時扣庫存，並發差
1、3步驟商品服務，操作商品服務的db，2、4步驟訂單服務，操作訂單服務的db。
避免存取不同服務的 db，原則上同一服務只能操作自身服務的 db。
MQ非同步化
首先考慮只將第4步非同步。
分析
2,4都是操作db，第4步不再等待，1、2、3成功後立即回饋給使用者。
之後透過訊息通知服務非同步下單，若第4步非同步下單失敗，重試操作，試圖重新產生訂單，MQ的訊息也可回溯。
訂單建立完成後，處於排隊狀態，然後服務發布一個事件Order Created 到訊息佇列中。
即訂單服務向外界發送訊息：我建立了一個訂單，由MQ 轉發給訂閱該訊息的服務。
如果商品服務收到建立訂單訊息之後執行扣庫存作業。注意，這裡可能因為某些不可抗因素導致扣庫存失敗，無論成功與否，商品服務都會發送一個扣庫存訊息到 MQ，訊息內容即扣庫存的結果。
訂單服務會訂閱扣庫存的結果，接收到該訊息後：
- 如果扣庫存成功，將訂單的狀態改為
已確認，即下單成功
- 如果扣庫存失敗，將訂單的狀態改為
已取消，即下單失敗
欲實現上述模型要求，需可靠的消息投遞。服務發出的消息，一定會被MQ收到。
商品/訂單服務都變成非同步化，適合秒殺類場景，當流量不大時，並不太適合。
非同步設計
- 在庫存在Redis中保存
- 收到請求Redis判斷是否有庫存充足,減掉Redis中庫存
- 訂單服務建立訂單寫入資料庫,並發送訊息
當訂單支付成功後，會有一個出庫過程，既然有這個過程，就有可能出庫失敗。
庫存有兩個部分：
- 當客服新增5個庫存，則快取redis和資料庫mysql層都需增加5個庫存，使用分散式交易的最終一致性來滿足：庫存要麼全加，要麼全不加。
- 當訂單產生時，需要扣除庫存，
先扣redis庫存，如果扣除成功，則產生訂單進行支付，這個過程不扣除mysql庫存。
- 當redis庫存扣完，產品就無法下單了，下單就會失敗，就把外層的給擋住了。
- 在第2步
扣除redis庫存成功後，產生訂單，進行支付，支付成功，返回我的訂單中心， 會發現有一個出庫流程。
-
出庫過程
一個MQ異步解耦的任務佇列，這個過程是扣除mysql庫存：
- 如果扣mysql庫存成功，出庫成功，完成下訂單整個流程，進入發貨狀態
- 如果扣mysql庫存失敗，出庫失敗，進行一系列的操作
redis庫存和mysql庫存
支付前是預扣，是扣redis庫存，是鎖定庫存的過程
支付後是真正扣，扣mysql庫存，確保庫存最終一致
但是，在極端情況下會存在資料不一致
- 如果redis庫存= mysql庫存，不會有問題
- 如果redis庫存< ; mysql庫存，不會有超賣問題，但會存在實際有庫存，但是沒有賣的情況
- 如果redis庫存> mysql庫存，就會超賣，超賣的訂單，在出庫的過程中會失敗
這樣整體不會出問題，mysql資料庫層，保證庫存最終不會出問題。
問題
#
資料庫庫存和redis庫存不一致，如何偵測？
如果偵測出來不一致，如何同步
沒有想出來好的方案
比較暴力的方式，就是找一個低高峰期，譬如凌晨1點，週期性強行覆蓋。但極端情況下還是會存在同步後不準確，譬如在同步的過程中，剛好有一個訂單在支付，這個訂單支付成功後，出庫的過程中，扣除了mysql的庫存，但是沒有扣除redis的庫存
這個就是資料庫同步快取的更新機制方面的問題
屬於一致性的邏輯設計的問題
快取數= 資料庫庫存數- 待扣數
當然這裡面也還有其它的方案，以及考慮到一致性的要求高低，可以使用簡單或複雜的方案
就看系統複雜度了，越是大系統就要拆得越細
比如待扣數又可以放到一個佇列裡面，或快取裡面，同時有計數，直接讀計數就行
比如放到mongo，已支付待出庫的數量，一般也不會很大，count一下，也不會損失多少
所以一般系統都無法完全保障資料鏈不出錯，但一定要有補償，就是出錯了可以糾錯
要保障不出錯的代價顯然太大
同步是有一套刷新機制，可以定時，也可以透過MQ，或監控不一至同步等等。 。 。
也叫做保障快取資料的新鮮度
一般不會太長時間，半小時，幾分鐘都有可能，不同場景需求不一樣
12306
買火車票的12306，晚上的時間都不能買票，這個時間估計是在同步庫存，將數據庫庫存同步到redis庫存中， 但是買火車票之類，在訂單生成前，必須扣除實際庫存，也就是要扣除mysql的庫存，
因為買火車票和購物不一樣，購物可以付款後出庫，但是買票這種，支付前就必須出庫，因此，要將出庫流程提前， 只有出庫成功，才能產生訂單，同樣要引入redis庫存
先扣緩存中的庫存，扣除成功後，然後才可以去扣mysql中的庫存。
如果扣除快取中的庫存失敗，就會擋在外面，返回庫存不足，這些請求不會穿刺到mysql中，擋住了大多數的請求壓力。
redis庫存會和mysql庫存不一致，極端情況下是肯定有的，需要進行庫存同步
#
以上是解決Redis庫存超賣問題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
