[[404811]]

今天我們來(lái)探討下扣減庫(kù)存的方案。

生活中，我們總是用各種電商 APP 搶購(gòu)商品，但是庫(kù)存數(shù)是很少的，特別是秒殺場(chǎng)景，商品可能就一件，那如何保證不會(huì)出現(xiàn)超賣(mài)的情況呢?

一、扣減庫(kù)存的三種方案

1.1 下單減庫(kù)存

用戶下單時(shí)減庫(kù)存

優(yōu)點(diǎn)：實(shí)時(shí)減庫(kù)存，避免付款時(shí)因庫(kù)存不足減庫(kù)存的問(wèn)題

缺點(diǎn)：惡意買(mǎi)家大量下單，將庫(kù)存用完，但是不付款，真正想買(mǎi)的人買(mǎi)不到

1.2 付款減庫(kù)存

下單頁(yè)面顯示最新的庫(kù)存，下單時(shí)不會(huì)立即減庫(kù)存，而是等到支付時(shí)才會(huì)減庫(kù)存。

優(yōu)點(diǎn)：防止惡意買(mǎi)家大量下單用光庫(kù)存，避免下單減庫(kù)存的缺點(diǎn)

缺點(diǎn)：下單頁(yè)面顯示的庫(kù)存數(shù)可能不是最新的庫(kù)存數(shù)，而庫(kù)存數(shù)用完后，下單頁(yè)面的庫(kù)存數(shù)沒(méi)有刷新，出現(xiàn)下單數(shù)超過(guò)庫(kù)存數(shù)，若支付的訂單數(shù)超過(guò)庫(kù)存數(shù)，則會(huì)出現(xiàn)支付失敗。

1.3 預(yù)扣庫(kù)存

下單頁(yè)面顯示最新的庫(kù)存，下單后保留這個(gè)庫(kù)存一段時(shí)間(比如10分鐘)，超過(guò)保留時(shí)間后，庫(kù)存釋放。若保留時(shí)間過(guò)后再支付，如果沒(méi)有庫(kù)存，則支付失敗。

優(yōu)點(diǎn)：結(jié)合下單減庫(kù)存的優(yōu)點(diǎn)，實(shí)時(shí)減庫(kù)存，且緩解惡意買(mǎi)家大量下單的問(wèn)題，保留時(shí)間內(nèi)未支付，則釋放庫(kù)存。

缺點(diǎn)：保留時(shí)間內(nèi)，惡意買(mǎi)家大量下單將庫(kù)存用完。并發(fā)量很高的時(shí)候，依然會(huì)出現(xiàn)下單數(shù)超過(guò)庫(kù)存數(shù)。

二、如何解決惡意買(mǎi)家下單的問(wèn)題

這里的惡意買(mǎi)家指短時(shí)間內(nèi)大量下單，將庫(kù)存用完的買(mǎi)家。

2.1 限制用戶下單數(shù)量

優(yōu)點(diǎn)：限制惡意買(mǎi)家下單

缺點(diǎn)：用戶想要多買(mǎi)幾件，被限制了，會(huì)降低銷(xiāo)售量

2.2 標(biāo)識(shí)惡意買(mǎi)家

通過(guò)標(biāo)識(shí)用戶的設(shè)備 id 或者會(huì)員 id，將用戶加入黑名單，不足之處是有些用戶是模擬的，識(shí)別不出來(lái)是不是真正的惡意買(mǎi)家。

三、如何解決下單成功而支付失敗(庫(kù)存不足)的問(wèn)題

3.1 備用庫(kù)存

商品庫(kù)存用完后，如果還有用戶支付，直接扣減備用庫(kù)存。

優(yōu)點(diǎn)：緩解部分用戶支付失敗的問(wèn)題。

缺點(diǎn)：備用庫(kù)存只能緩解問(wèn)題，不能從根本上解決問(wèn)題。另外備用庫(kù)存針對(duì)普通商品可以，針對(duì)特殊商品這種庫(kù)存少的，備用庫(kù)存量也不會(huì)很大，還是會(huì)出現(xiàn)大量用戶下單成功卻因庫(kù)存不足而支付失敗的問(wèn)題。

四、如何解決高并發(fā)下庫(kù)存超賣(mài)的場(chǎng)景

庫(kù)存超賣(mài)最簡(jiǎn)單的解釋就是多成交了訂單而發(fā)不了貨。

場(chǎng)景

用戶 A 和 B 成功下單，在支付時(shí)扣減庫(kù)存，當(dāng)前庫(kù)存數(shù)為 10。因 A 和 B 查詢庫(kù)存時(shí)，都還有庫(kù)存數(shù)，所以 A 和 B 都可以付款。

A 和 B 同時(shí)支付，A 和 B 支付完成后，可以看做兩個(gè)請(qǐng)求回調(diào)后臺(tái)系統(tǒng)扣減庫(kù)存，有兩個(gè)線程處理請(qǐng)求，兩個(gè)線程查詢出來(lái)的庫(kù)存數(shù) inventory = 10。

然后 A 線程更新最終庫(kù)存數(shù) ：

lastInventory = inventory - 1 = 9， 

B 線程更新庫(kù)存數(shù)：

lastInventory = inventory - 1 = 9。 

而實(shí)際最終的庫(kù)存應(yīng)是 8 才對(duì)，這樣就出現(xiàn)庫(kù)存超賣(mài)的情況，而發(fā)不出貨。

那如何解決庫(kù)存超賣(mài)的情況呢?

以下方案都是基于數(shù)據(jù)庫(kù)層面的。有些同學(xué)可能會(huì)問(wèn)，是不是可以用 Redis 分布式鎖來(lái)，后面會(huì)講到。

方案一

SQL語(yǔ)句直接更新庫(kù)存，而不是先查詢出來(lái)，然后賦值

UPDATE [庫(kù)存表] SET 庫(kù)存數(shù) - 1 

方案二

SQL語(yǔ)句更新庫(kù)存時(shí)，如果扣減庫(kù)存后，庫(kù)存數(shù)為負(fù)數(shù)，直接拋異常，利用事務(wù)的原子性進(jìn)行自動(dòng)回滾。

方案三

利用SQL語(yǔ)句更新庫(kù)存，防止庫(kù)存為負(fù)數(shù)

UPDATE [庫(kù)存表] SET 庫(kù)存數(shù) - 1 WHERE 庫(kù)存數(shù) - 1 > 0 

如果影響條數(shù)大于1，則表示扣減庫(kù)存成功，否則不更新庫(kù)存，并退款。

五、秒殺場(chǎng)景下如何扣減庫(kù)存

5.1 采用下單減庫(kù)存

因秒殺場(chǎng)景下，大部分用戶都是想直接購(gòu)買(mǎi)商品的，可以直接用下單減庫(kù)存。

大量用戶和惡意用戶都是同時(shí)進(jìn)行的，區(qū)別是正常用戶會(huì)直接購(gòu)買(mǎi)商品，惡意用戶雖然在競(jìng)爭(zhēng)搶購(gòu)的名額，但是獲取到的資格和普通用戶一樣，所以下單減庫(kù)存在秒殺場(chǎng)景下，惡意用戶下單并不能造成之前說(shuō)的缺點(diǎn)。

而且下單直接扣減庫(kù)存，這個(gè)方案更簡(jiǎn)單，在第一步就扣減庫(kù)存了。

5.2 Redis 緩存

查詢緩存要比查詢數(shù)據(jù)庫(kù)快，所以將庫(kù)存數(shù)放在緩存中，直接在緩存中扣減庫(kù)存。

5.3 限流

秒殺場(chǎng)景中，對(duì)請(qǐng)求做了很多限流操作，比如前端頁(yè)面的限流和后端令牌桶限流，真正到扣減庫(kù)存那一步時(shí)，請(qǐng)求數(shù)很少了。所以限流常用在秒殺方案中，感覺(jué)可以再寫(xiě)一篇限流的文章了～

另外其實(shí)真實(shí)的項(xiàng)目中，用到了更多的機(jī)制來(lái)保證能夠正?？蹨p庫(kù)存，本篇是拋磚引入，希望大家提出寶貴的建議和方案～。

贈(zèng)送一張秒殺場(chǎng)景方案總結(jié)：

本文轉(zhuǎn)載自微信公眾號(hào)「悟空聊架構(gòu)」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系悟空聊架構(gòu)眾號(hào)。