這篇文章主要介紹“Redis如何解決庫存超賣問題”，在日常操作中，相信很多人在Redis如何解決庫存超賣問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Redis如何解決庫存超賣問題”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！
為市中等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及市中網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為做網(wǎng)站、網(wǎng)站建設(shè)、市中網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！商品服務(wù)的庫存變化時，通過 MQ 通知訂單服務(wù)庫存變化。
查詢商品信息 (調(diào)用商品服務(wù))
計算總價(生成訂單詳情)
商品服務(wù)扣庫存(調(diào)用商品服務(wù))
訂單入庫( 生成訂單)
// 原始的MySQL同步流程 // 判斷此代金券是否加入搶購 SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId); AssertUtil.isTrue(seckillVouchers == null, "該代金券并未有搶購活動"); // 判斷是否有效 AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, "該活動已結(jié)束"); // 插入數(shù)據(jù)庫 seckillVouchersMapper.save(seckillVouchers);
在訂單生成時直接扣庫存，這是最原始的扣庫存方案，比較簡單，但存在問題
可能導(dǎo)致很多訂單把產(chǎn)品庫存扣除而未支付，這就需要有一個后臺腳本，將一段時間內(nèi)沒有支付的訂單的庫存釋放，把訂單取消即時扣庫存，并發(fā)差
1、3步商品服務(wù)，操作商品服務(wù)的 db，2、4步訂單服務(wù)，操作訂單服務(wù)的 db。
避免訪問不同服務(wù)的 db，原則上同一服務(wù)只能操作自身服務(wù)的 db。
首先考慮只將第4步異步。
2,4都是操作db，第4步不再等待，1、2、3成功后立即反饋給用戶。
之后通過消息通知服務(wù)異步下單，若第4步異步下單失敗，重試操作，試圖重新生成訂單，MQ的消息也可回溯。
訂單創(chuàng)建完成后，處于排隊狀態(tài)，然后服務(wù)發(fā)布一個事件Order Created 到消息隊列中。
即訂單服務(wù)向外界發(fā)送消息：我創(chuàng)建了一個訂單，由MQ 轉(zhuǎn)發(fā)給訂閱該消息的服務(wù)
如果商品服務(wù)收到創(chuàng)建訂單消息之后執(zhí)行扣庫存操作。注意，這里可能因為某些不可抗因素導(dǎo)致扣庫存失敗，無論成功與否，商品服務(wù)都會發(fā)送一個扣庫存消息到 MQ，消息內(nèi)容即扣庫存的結(jié)果。
訂單服務(wù)會訂閱扣庫存的結(jié)果，接收到該消息后：
如果扣庫存成功，將訂單的狀態(tài)改為已確認(rèn)，即下單成功
如果扣庫存失敗，將訂單的狀態(tài)改為已取消，即下單失敗
欲實(shí)現(xiàn)上述模型要求，需可靠的消息投遞。服務(wù)發(fā)出的消息，一定會被MQ收到。
用戶體驗的變化，前端配合排隊中等界面。
商品/訂單服務(wù)都變成異步化，適合秒殺類場景，當(dāng)流量不大時，并不太適合。
庫存在Redis中保存
收到請求Redis判斷是否庫存充足 ,減掉Redis中庫存
訂單服務(wù)創(chuàng)建訂單寫入數(shù)據(jù)庫,并發(fā)送消息
當(dāng)訂單支付成功后，會有一個出庫過程，既然有這個過程，就有可能出庫失敗。
庫存有兩部分：
緩存redis層
數(shù)據(jù)庫mysql層
當(dāng)客服新增5個庫存，則緩存redis和數(shù)據(jù)庫mysql層都需增加5個庫存，使用分布式事務(wù)的最終一致性來滿足：庫存要么全加，要么全不加。
當(dāng)訂單生成時，需要扣除庫存，先扣redis庫存，如果扣除成功，則生成訂單進(jìn)行支付，這個過程不扣除mysql庫存。
當(dāng)redis庫存扣完，該產(chǎn)品就無法下單了，下單就會失敗，就把外層的給擋住了。
在第2步扣除redis庫存成功后，生成訂單，進(jìn)行支付，支付成功，返回我的訂單中心， 會發(fā)現(xiàn)有一個出庫過程。
出庫過程一個MQ異步解耦的任務(wù)隊列，這個過程是扣除mysql庫存：
如果扣mysql庫存成功，出庫成功，完成下訂單整個流程，進(jìn)入發(fā)貨狀態(tài)
如果扣mysql庫存失敗，出庫失敗，進(jìn)行一系列的操作
訂單狀態(tài)改成取消
返還redis庫存
退款
支付前是預(yù)扣，是扣redis庫存，是鎖定庫存的過程
支付后是真正扣，扣mysql庫存，保證庫存最終一致
但是，在極端情況下會存在數(shù)據(jù)不一致
如果redis庫存 = mysql庫存，不會有問題
如果redis庫存 < mysql庫存，不會有超賣問題，但會存在實(shí)際有庫存，但是沒有賣的情況
如果redis庫存 > mysql庫存，就會超賣，超賣的訂單，在出庫的過程中會失敗
這樣總體不會出問題，mysql數(shù)據(jù)庫層，保證庫存最終不會出問題。
數(shù)據(jù)庫庫存和redis庫存不一致，如何檢測？
如果檢測出來不一致，如何同步
沒有想出來好的方案
比較暴力的方式，就是找一個低峰期，譬如凌晨1點(diǎn)，周期性強(qiáng)行覆蓋。 但是極端情況下還是會存在同步后不準(zhǔn)確，譬如在同步的過程中，剛好有一個訂單在支付，這個訂單支付成功后，出庫的過程中，扣除了mysql的庫存，但是沒有扣除redis的庫存
這個就是數(shù)據(jù)庫同步緩存的更新機(jī)制方面的問題
屬于一致性的邏輯設(shè)計的問題緩存數(shù) = 數(shù)據(jù)庫庫存數(shù) - 待扣數(shù)
當(dāng)然這里面也還有其它的方案，以及考慮到一致性的要求高低，可以使用簡單或復(fù)雜的方案
就看系統(tǒng)復(fù)雜度了，越是大系統(tǒng)就要拆得越細(xì)
比如待扣數(shù)又可以放到一個隊列里面，或者緩存里面，同時有計數(shù)，直接讀計數(shù)就行
比如放到mongo，已支付待出庫的數(shù)量，一般也不會很大，count一下，也不會損失多少
所以一般系統(tǒng)都不能完全保障數(shù)據(jù)鏈不出錯，但一定要有補(bǔ)償，就是出錯了可以糾錯
要保障不出錯的代價顯然太大
同步是有一套刷新機(jī)制，可以定時，也可以通過MQ，或者監(jiān)控不一至同步等等。。。
也叫做保障緩存數(shù)據(jù)的新鮮度
一般不會太長時間，半小時，幾分鐘都有可能，不同場景需求不一樣
12306
買火車票的12306，晚上的時間都不能買票，這個時間估計是在同步庫存，將數(shù)據(jù)庫庫存同步到redis庫存中， 但是買火車票之類，在訂單生成前，必須扣除實(shí)際庫存，也就是要扣除mysql的庫存，
因為買火車票和購物不一樣，購物可以付款后出庫，但是買票這種，支付前就必須出庫，因此，要將出庫過程提前， 只有出庫成功，才能生成訂單，同樣要引入redis庫存
先扣緩存中的庫存，扣除成功后，然后才可以去扣mysql中的庫存。
如果扣除緩存中的庫存失敗，就會擋在外面，返回庫存不足，這些請求不會穿刺到mysql中，擋住了大多數(shù)的請求壓力。
redis庫存會和mysql庫存不一致，極端情況下是肯定有的，需要進(jìn)行庫存同步
當(dāng)緩存庫存比數(shù)據(jù)庫庫存多，那么就會出現(xiàn)，查詢有票，但是就無法下單，下單的時候就說庫存不足，這個情況下，就會造成數(shù)據(jù)庫壓力過大，不過12306應(yīng)該有其他手段來規(guī)避這個問題，不過，我確實(shí)遇到過，查詢的時候有票，但是無法下單的情況。
當(dāng)緩存庫存比數(shù)據(jù)庫緩存少，那么不會出問題，只會出現(xiàn)有票，但是沒有出售的情況，等完成庫存同步一下， 明天又準(zhǔn)確了。
到此，關(guān)于“Redis如何解決庫存超賣問題”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
重慶分公司
重慶分公司
