這篇文章主要介紹“Redis如何解決庫(kù)存超賣問(wèn)題”，在日常操作中，相信很多人在Redis如何解決庫(kù)存超賣問(wèn)題問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Redis如何解決庫(kù)存超賣問(wèn)題”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

為市中等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及市中網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為做網(wǎng)站、網(wǎng)站建設(shè)、市中網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

商品和訂單服務(wù)間使用MQ

商品服務(wù)的庫(kù)存變化時(shí)，通過(guò) MQ 通知訂單服務(wù)庫(kù)存變化。

原始的同步流程

1. 查詢商品信息 (調(diào)用商品服務(wù))

2. 計(jì)算總價(jià)(生成訂單詳情)

3. 商品服務(wù)扣庫(kù)存(調(diào)用商品服務(wù))

4. 訂單入庫(kù)( 生成訂單)

// 原始的MySQL同步流程
// 判斷此代金券是否加入搶購(gòu)
SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId);
AssertUtil.isTrue(seckillVouchers == null, "該代金券并未有搶購(gòu)活動(dòng)");
// 判斷是否有效
AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, "該活動(dòng)已結(jié)束");
// 插入數(shù)據(jù)庫(kù)
seckillVouchersMapper.save(seckillVouchers);

在訂單生成時(shí)直接扣庫(kù)存，這是最原始的扣庫(kù)存方案，比較簡(jiǎn)單，但存在問(wèn)題

• 可能導(dǎo)致很多訂單把產(chǎn)品庫(kù)存扣除而未支付，這就需要有一個(gè)后臺(tái)腳本，將一段時(shí)間內(nèi)沒(méi)有支付的訂單的庫(kù)存釋放，把訂單取消即時(shí)扣庫(kù)存，并發(fā)差

• 1、3步商品服務(wù)，操作商品服務(wù)的 db，2、4步訂單服務(wù)，操作訂單服務(wù)的 db。

避免訪問(wèn)不同服務(wù)的 db，原則上同一服務(wù)只能操作自身服務(wù)的 db。

MQ異步化

首先考慮只將第4步異步。

分析

2,4都是操作db，第4步不再等待，1、2、3成功后立即反饋給用戶。

之后通過(guò)消息通知服務(wù)異步下單，若第4步異步下單失敗，重試操作，試圖重新生成訂單，MQ的消息也可回溯。

訂單創(chuàng)建完成后，處于排隊(duì)狀態(tài)，然后服務(wù)發(fā)布一個(gè)事件Order Created 到消息隊(duì)列中。
即訂單服務(wù)向外界發(fā)送消息：我創(chuàng)建了一個(gè)訂單，由MQ 轉(zhuǎn)發(fā)給訂閱該消息的服務(wù)

如果商品服務(wù)收到創(chuàng)建訂單消息之后執(zhí)行扣庫(kù)存操作。注意，這里可能因?yàn)槟承┎豢煽挂蛩貙?dǎo)致扣庫(kù)存失敗，無(wú)論成功與否，商品服務(wù)都會(huì)發(fā)送一個(gè)扣庫(kù)存消息到 MQ，消息內(nèi)容即扣庫(kù)存的結(jié)果。
訂單服務(wù)會(huì)訂閱扣庫(kù)存的結(jié)果，接收到該消息后：

• 如果扣庫(kù)存成功，將訂單的狀態(tài)改為已確認(rèn)，即下單成功

• 如果扣庫(kù)存失敗，將訂單的狀態(tài)改為已取消，即下單失敗

欲實(shí)現(xiàn)上述模型要求，需可靠的消息投遞。服務(wù)發(fā)出的消息，一定會(huì)被MQ收到。

• 用戶體驗(yàn)的變化，前端配合排隊(duì)中等界面。

商品/訂單服務(wù)都變成異步化，適合秒殺類場(chǎng)景，當(dāng)流量不大時(shí)，并不太適合。

異步設(shè)計(jì)

1. 庫(kù)存在Redis中保存

2. 收到請(qǐng)求Redis判斷是否庫(kù)存充足 ,減掉Redis中庫(kù)存

3. 訂單服務(wù)創(chuàng)建訂單寫入數(shù)據(jù)庫(kù),并發(fā)送消息

當(dāng)訂單支付成功后，會(huì)有一個(gè)出庫(kù)過(guò)程，既然有這個(gè)過(guò)程，就有可能出庫(kù)失敗。
庫(kù)存有兩部分：

• 緩存redis層

• 數(shù)據(jù)庫(kù)mysql層

1. 當(dāng)客服新增5個(gè)庫(kù)存，則緩存redis和數(shù)據(jù)庫(kù)mysql層都需增加5個(gè)庫(kù)存，使用分布式事務(wù)的最終一致性來(lái)滿足：庫(kù)存要么全加，要么全不加。

2. 當(dāng)訂單生成時(shí)，需要扣除庫(kù)存，先扣redis庫(kù)存，如果扣除成功，則生成訂單進(jìn)行支付，這個(gè)過(guò)程不扣除mysql庫(kù)存。

3. 當(dāng)redis庫(kù)存扣完，該產(chǎn)品就無(wú)法下單了，下單就會(huì)失敗，就把外層的給擋住了。

4. 在第2步扣除redis庫(kù)存成功后，生成訂單，進(jìn)行支付，支付成功，返回我的訂單中心， 會(huì)發(fā)現(xiàn)有一個(gè)出庫(kù)過(guò)程。

5. 出庫(kù)過(guò)程一個(gè)MQ異步解耦的任務(wù)隊(duì)列，這個(gè)過(guò)程是扣除mysql庫(kù)存：

• 如果扣mysql庫(kù)存成功，出庫(kù)成功，完成下訂單整個(gè)流程，進(jìn)入發(fā)貨狀態(tài)

• 如果扣mysql庫(kù)存失敗，出庫(kù)失敗，進(jìn)行一系列的操作

1. 訂單狀態(tài)改成取消

2. 返還redis庫(kù)存

3. 退款

redis庫(kù)存和mysql庫(kù)存

支付前是預(yù)扣，是扣redis庫(kù)存，是鎖定庫(kù)存的過(guò)程
支付后是真正扣，扣mysql庫(kù)存，保證庫(kù)存最終一致

但是，在極端情況下會(huì)存在數(shù)據(jù)不一致

• 如果redis庫(kù)存 = mysql庫(kù)存，不會(huì)有問(wèn)題

• 如果redis庫(kù)存 < mysql庫(kù)存，不會(huì)有超賣問(wèn)題，但會(huì)存在實(shí)際有庫(kù)存，但是沒(méi)有賣的情況

• 如果redis庫(kù)存 > mysql庫(kù)存，就會(huì)超賣，超賣的訂單，在出庫(kù)的過(guò)程中會(huì)失敗

這樣總體不會(huì)出問(wèn)題，mysql數(shù)據(jù)庫(kù)層，保證庫(kù)存最終不會(huì)出問(wèn)題。

問(wèn)題

數(shù)據(jù)庫(kù)庫(kù)存和redis庫(kù)存不一致，如何檢測(cè)？

如果檢測(cè)出來(lái)不一致，如何同步

沒(méi)有想出來(lái)好的方案
比較暴力的方式，就是找一個(gè)低峰期，譬如凌晨1點(diǎn)，周期性強(qiáng)行覆蓋。 但是極端情況下還是會(huì)存在同步后不準(zhǔn)確，譬如在同步的過(guò)程中，剛好有一個(gè)訂單在支付，這個(gè)訂單支付成功后，出庫(kù)的過(guò)程中，扣除了mysql的庫(kù)存，但是沒(méi)有扣除redis的庫(kù)存

這個(gè)就是數(shù)據(jù)庫(kù)同步緩存的更新機(jī)制方面的問(wèn)題
屬于一致性的邏輯設(shè)計(jì)的問(wèn)題
緩存數(shù) = 數(shù)據(jù)庫(kù)庫(kù)存數(shù) - 待扣數(shù)
當(dāng)然這里面也還有其它的方案，以及考慮到一致性的要求高低，可以使用簡(jiǎn)單或復(fù)雜的方案
就看系統(tǒng)復(fù)雜度了，越是大系統(tǒng)就要拆得越細(xì)
比如待扣數(shù)又可以放到一個(gè)隊(duì)列里面，或者緩存里面，同時(shí)有計(jì)數(shù)，直接讀計(jì)數(shù)就行
比如放到mongo，已支付待出庫(kù)的數(shù)量，一般也不會(huì)很大，count一下，也不會(huì)損失多少
所以一般系統(tǒng)都不能完全保障數(shù)據(jù)鏈不出錯(cuò)，但一定要有補(bǔ)償，就是出錯(cuò)了可以糾錯(cuò)
要保障不出錯(cuò)的代價(jià)顯然太大
同步是有一套刷新機(jī)制，可以定時(shí)，也可以通過(guò)MQ，或者監(jiān)控不一至同步等等。。。
也叫做保障緩存數(shù)據(jù)的新鮮度
一般不會(huì)太長(zhǎng)時(shí)間，半小時(shí)，幾分鐘都有可能，不同場(chǎng)景需求不一樣

12306

買火車票的12306，晚上的時(shí)間都不能買票，這個(gè)時(shí)間估計(jì)是在同步庫(kù)存，將數(shù)據(jù)庫(kù)庫(kù)存同步到redis庫(kù)存中， 但是買火車票之類，在訂單生成前，必須扣除實(shí)際庫(kù)存，也就是要扣除mysql的庫(kù)存，

因?yàn)橘I火車票和購(gòu)物不一樣，購(gòu)物可以付款后出庫(kù)，但是買票這種，支付前就必須出庫(kù)，因此，要將出庫(kù)過(guò)程提前， 只有出庫(kù)成功，才能生成訂單，同樣要引入redis庫(kù)存

先扣緩存中的庫(kù)存，扣除成功后，然后才可以去扣mysql中的庫(kù)存。

如果扣除緩存中的庫(kù)存失敗，就會(huì)擋在外面，返回庫(kù)存不足，這些請(qǐng)求不會(huì)穿刺到mysql中，擋住了大多數(shù)的請(qǐng)求壓力。

redis庫(kù)存會(huì)和mysql庫(kù)存不一致，極端情況下是肯定有的，需要進(jìn)行庫(kù)存同步

• 當(dāng)緩存庫(kù)存比數(shù)據(jù)庫(kù)庫(kù)存多，那么就會(huì)出現(xiàn)，查詢有票，但是就無(wú)法下單，下單的時(shí)候就說(shuō)庫(kù)存不足，這個(gè)情況下，就會(huì)造成數(shù)據(jù)庫(kù)壓力過(guò)大，不過(guò)12306應(yīng)該有其他手段來(lái)規(guī)避這個(gè)問(wèn)題，不過(guò)，我確實(shí)遇到過(guò)，查詢的時(shí)候有票，但是無(wú)法下單的情況。

• 當(dāng)緩存庫(kù)存比數(shù)據(jù)庫(kù)緩存少，那么不會(huì)出問(wèn)題，只會(huì)出現(xiàn)有票，但是沒(méi)有出售的情況，等完成庫(kù)存同步一下， 明天又準(zhǔn)確了。

到此，關(guān)于“Redis如何解決庫(kù)存超賣問(wèn)題”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

分享名稱：Redis如何解決庫(kù)存超賣問(wèn)題-創(chuàng)新互聯(lián)
分享鏈接：http://chinadenli.net/article22/cojsjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、網(wǎng)站改版、網(wǎng)站營(yíng)銷、網(wǎng)站收錄、做網(wǎng)站、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)