在大規(guī)模秒殺活動(dòng)中，針對(duì)單一商品的庫(kù)存扣減請(qǐng)求峰值可以輕松達(dá)到幾萬(wàn)、甚至幾十萬(wàn)QPS，如常見(jiàn)的搶茅臺(tái)活動(dòng)。在這種場(chǎng)景下再基于數(shù)據(jù)庫(kù)進(jìn)行庫(kù)存扣減就顯得無(wú)能為力了，記住一個(gè)關(guān)鍵指標(biāo)：在MySQL中，目前單行更新操作的的性能約為500QPS。對(duì)于動(dòng)輒幾萬(wàn)QPS的庫(kù)存扣減來(lái)說(shuō)，這個(gè)量級(jí)肯定是偏低了。

所以為了應(yīng)對(duì)這種高并發(fā)場(chǎng)景，業(yè)界提出了一種方案叫 熱點(diǎn)散列，即今天群里討論的庫(kù)存分桶。

其方案如下圖所示：將同一商品的庫(kù)存提前分配至多個(gè)“桶”中，根據(jù)路由規(guī)則（隨機(jī)、UID取模）將庫(kù)存請(qǐng)求路由至不同的桶，從而將集中于單實(shí)例的請(qǐng)求分散，此方案類似于水平擴(kuò)展。

圖片

至于“分桶”的技術(shù)實(shí)現(xiàn)，很多技術(shù)文章或解決方案都建議采用Redis來(lái)實(shí)現(xiàn)。具體而言，對(duì)任一秒殺活動(dòng)的商品，可將其分成N份，每份對(duì)一個(gè)緩存Key，緩存Key的構(gòu)成必須遵循一定的規(guī)律，便于路由，示例如下：

key: inventoryId_1，value: 庫(kù)存數(shù)量 

key: inventoryId_2,  value: 庫(kù)存數(shù)量 

... 

key: inventoryId_N,  value: 庫(kù)存數(shù)量

在扣減庫(kù)存時(shí)，可以根據(jù)Key的編號(hào)區(qū)間，采用隨機(jī)算法，UID取模等方式確定一個(gè)編號(hào)，然后組裝Key訪問(wèn)緩存。 

舉個(gè)例子，假如inventoryId為20221821，將庫(kù)存分配至100個(gè)桶，則根據(jù)相應(yīng)Key的區(qū)間為[1,100]。

服務(wù)端收到商品庫(kù)存扣減請(qǐng)求后，將請(qǐng)求中的參數(shù)UID取模，假設(shè)UID % 100 = 67，則組裝Key為 20221821_67，基于20221821_67扣減對(duì)應(yīng)緩存桶中的庫(kù)存。

熱點(diǎn)散列的核心思想為：在緩存中扣減庫(kù)存，以提升系統(tǒng)的吞吐量；緩存扣減成功后，異步向數(shù)據(jù)庫(kù)寫入庫(kù)存扣減流水并更新庫(kù)存；此外，還需要通過(guò)定時(shí)任務(wù)等機(jī)制實(shí)現(xiàn)緩存與數(shù)據(jù)庫(kù)的庫(kù)存總量同步。

這個(gè)方案看上去很不錯(cuò)，但也會(huì)存在如下三個(gè)問(wèn)題：

一、在緩存中扣減庫(kù)存如何保證冪等性呢？若冪等性防控不足，則可能出現(xiàn)重復(fù)扣減，進(jìn)而導(dǎo)致少賣。

二、緩存寫操作和數(shù)據(jù)庫(kù)寫操作無(wú)法通過(guò)事務(wù)機(jī)制來(lái)保證強(qiáng)一致性，那么該如何有效的保證庫(kù)存數(shù)據(jù)的一致性呢？

三、用戶所見(jiàn)的庫(kù)存應(yīng)為總庫(kù)存，即便總庫(kù)存充足，一旦分桶，如何保證用戶請(qǐng)求被路由到的分桶油足夠的庫(kù)存呢？

所以個(gè)人覺(jué)得，熱點(diǎn)散列在理論上是解決庫(kù)存熱點(diǎn)問(wèn)題最有效的方案，但在實(shí)際應(yīng)用中，需要考慮的細(xì)節(jié)非常多?；诰彺娴膸?kù)存扣減的方案是比較粗糙的，它只滿足一些特定場(chǎng)景的需要。對(duì)于淘寶、京東這類在想商品規(guī)模達(dá)數(shù)十億的大型電商平臺(tái)而言，所面臨的問(wèn)題要復(fù)雜得多，除了穩(wěn)定性、可靠性、一致性，還包括庫(kù)存分配，庫(kù)存碎片，庫(kù)存擴(kuò)縮容、流量?jī)A斜、商品少賣、商品超賣等。

上次去阿里交流的時(shí)候，阿里專家唐三說(shuō)：在阿里，庫(kù)存架構(gòu)采用的方案是做庫(kù)存單元化架構(gòu)，這種方案應(yīng)該是大型電商平臺(tái)庫(kù)存系統(tǒng)的終極解決方案。