簡單庫存場景的數(shù)據(jù)庫實(shí)現(xiàn)

一般來說，從數(shù)據(jù)庫層面講，庫存業(yè)務(wù)會(huì)分為兩步，第一步是插入一條記錄到扣減明細(xì)表inventory_detail，第二步是對庫存扣減表inventory的一條記錄進(jìn)行扣減，這兩步往往是在一個(gè)事務(wù)中實(shí)現(xiàn)的。

數(shù)據(jù)庫業(yè)務(wù)架構(gòu)圖如下，所有的請求均發(fā)往同一個(gè)Database。

從上文的架構(gòu)圖不難看出，所有的商品的庫存信息都存在單一的表和庫里，當(dāng)商品種類繁多或者業(yè)務(wù)并發(fā)請求暴漲時(shí)，單實(shí)例的數(shù)據(jù)庫顯然會(huì)成為容量或者性能瓶頸。該數(shù)據(jù)庫架構(gòu)一般只是功能性的實(shí)現(xiàn)，主要用于微型庫存系統(tǒng)或者測試使用。

高并發(fā)庫存系統(tǒng)的數(shù)據(jù)庫實(shí)現(xiàn)

為了解決單實(shí)例存在的容量和性能上限問題，阿里巴巴所有的庫存系統(tǒng)在十年前就實(shí)現(xiàn)了分庫分表設(shè)計(jì),主要通過數(shù)據(jù)的水平拆分實(shí)現(xiàn)不同商品的庫存扣減請求路由到不同的數(shù)據(jù)庫?；緮?shù)據(jù)庫架構(gòu)圖如下

從上圖不難看出，庫存扣減表和扣減明細(xì)表一般都使用商品id作為片鍵，這樣可以保證滿足整個(gè)系統(tǒng)在高并發(fā)扣減請求的同時(shí)，同一商品的庫存扣減操作和添加明細(xì)操作在同一個(gè)事務(wù)中實(shí)現(xiàn)。如果數(shù)據(jù)分布和業(yè)務(wù)請求足夠均勻，理論上經(jīng)過分庫分表設(shè)計(jì)后，整個(gè)系統(tǒng)的吞吐量將會(huì)是線性的增長，主要取決于分實(shí)例的數(shù)量。

熱點(diǎn)行更新

在電商業(yè)務(wù)中，商家活動(dòng)比如秒殺不可避免。秒殺活動(dòng)會(huì)給電商庫存系統(tǒng)帶來巨大的挑戰(zhàn)，尤其體現(xiàn)在數(shù)據(jù)庫層面。因?yàn)橥粋€(gè)商品id對應(yīng)于數(shù)據(jù)庫的一行記錄，所以在DB架構(gòu)上按照商品維度做了分庫分表也是無效的。而更新這行記錄時(shí)必然需要給這行記錄加X鎖。熱點(diǎn)商品的庫存扣減本質(zhì)上就是熱點(diǎn)行更新的能力，高并發(fā)的同行更新會(huì)造成嚴(yán)重的行鎖等待現(xiàn)象，從而導(dǎo)致數(shù)據(jù)庫的threads_running和rt飆升，造成雪崩。在當(dāng)前的官方mysql中，一般單行更新的QPS在500以內(nèi)，對于熱點(diǎn)商品的秒殺需求，這個(gè)量往往是不達(dá)標(biāo)的。

阿里巴巴PolarDB-X數(shù)據(jù)庫團(tuán)隊(duì)基于以上場景的需求，針對內(nèi)核優(yōu)化，引入了先進(jìn)的水車模型，在識(shí)別出熱點(diǎn)SQL后，實(shí)現(xiàn)了在內(nèi)核層面優(yōu)化處理，相比官方MySQL提高了10倍以上的熱點(diǎn)行扣減能力,廣泛應(yīng)用于集團(tuán)電商庫存集群，資金平臺(tái)，權(quán)益發(fā)放平臺(tái)等核心數(shù)據(jù)庫集群。

其主要的核心思想是：針對應(yīng)用層SQL做輕量化改造，帶上"熱點(diǎn)行SQL"的標(biāo)簽，當(dāng)這種SQL進(jìn)入內(nèi)核后，在內(nèi)存中維護(hù)一個(gè)hash表，將主鍵或唯一鍵相同的請求(一般也就是同一商品id)hash到同一個(gè)地方做請求的合并，經(jīng)過一段時(shí)間后(默認(rèn)100us)統(tǒng)一提交，從而實(shí)現(xiàn)了將串行處理變成了批處理，讓每個(gè)熱點(diǎn)行更新請求并不需要都去掃描和更新btree。

類似原理，阿里云RDS數(shù)據(jù)庫團(tuán)隊(duì)同樣在內(nèi)核層面針對熱點(diǎn)行更新做了大量的優(yōu)化，核心思路為引入SQL語句的排隊(duì)機(jī)制，將可能存在行鎖沖突的語句放在一個(gè)組內(nèi)排序，從而減少行鎖沖突帶來的額外系統(tǒng)開銷。Statement Queque和Inventory Hint可以結(jié)合使用，不過在事務(wù)中，熱點(diǎn)行更新必須是該事務(wù)的最后一條記錄，因?yàn)閏ommit on success的機(jī)制存在，一旦該SQL執(zhí)行成功就會(huì)自動(dòng)提交或自動(dòng)回滾。簡單的使用范例如下

begin; 
insert into inventory_detail(inventory_id,user_id) values(1,1); 
update /*+ ccl_queue_value(1) commit_on_success rollback_on_fail target_affect_row(1) */ inventory set inventory_count=inventory_count+1 where inventory_id=1  

更多文檔參考inventory hint statement queue

業(yè)務(wù)架構(gòu)優(yōu)化

冪等性實(shí)現(xiàn)

在庫存數(shù)據(jù)庫系統(tǒng)中，一般都會(huì)在更新庫存記錄后，寫入一條庫存扣減明細(xì)的流水記錄，用于后續(xù)可能存在的查詢需求。舉個(gè)例子，在集團(tuán)的權(quán)益發(fā)放平臺(tái)中，庫存流水記錄主要用于實(shí)現(xiàn)庫存扣減的冪等性，即同一個(gè)用戶只能領(lǐng)取一次權(quán)益。在系統(tǒng)的實(shí)際運(yùn)行過程中，可能因?yàn)橐恍┚W(wǎng)絡(luò)故障等其他原因，當(dāng)?shù)讓訑?shù)據(jù)庫的扣減成功以后并沒有成功返回給用戶時(shí)，用戶可能會(huì)有重試操作，這時(shí)就必須避免庫存記錄的重復(fù)扣減情況。所以針對這些情況，應(yīng)用在設(shè)計(jì)時(shí)會(huì)考慮先查詢一遍庫存流水記錄，如果該用戶已經(jīng)領(lǐng)取過該權(quán)益，則不再重復(fù)扣減，直接返回。為了實(shí)現(xiàn)這種強(qiáng)冪等性的需求，庫存扣減和插入流水就必須在同一個(gè)事務(wù)中，滿足同時(shí)成功或同時(shí)失敗。

基于緩存的分桶扣減方案

在更大規(guī)模,針對單一商品的超高并發(fā)扣減的庫存集群中，可能基于數(shù)據(jù)庫內(nèi)核的改造優(yōu)化還無法滿足業(yè)務(wù)需求。單一商品的超高并發(fā)扣減可能會(huì)影響到同一數(shù)據(jù)庫實(shí)例上的其他商品扣減，同一個(gè)數(shù)據(jù)庫實(shí)例上也可能存在多個(gè)熱點(diǎn)商品造成互相影響，這時(shí)就需要考慮在業(yè)務(wù)和數(shù)據(jù)庫架構(gòu)上再做一次升級，我們引入基于緩存的分桶扣減方案。

下圖為該方案數(shù)據(jù)庫架構(gòu)圖，基于緩存的分桶扣減方案的主要思路為

• 1、普通的非熱點(diǎn)商品，或者并發(fā)度不夠大的熱點(diǎn)商品走強(qiáng)冪等性的分庫分表+數(shù)據(jù)庫內(nèi)核改造優(yōu)化

• 2、超大熱點(diǎn)商品，針對該商品再做多key拆分，先走弱冪等性的緩存扣減，緩存扣減后，異步往DB寫入一條庫存流水記錄，后續(xù)再做緩存與數(shù)據(jù)庫的庫存總量同步

在分桶方案詳細(xì)落地實(shí)現(xiàn)上，需要考慮的細(xì)節(jié)問題會(huì)多很多，比較重要的有以下幾點(diǎn)

1、分桶管理

為了更通俗和直觀的描述，緩存集群的一個(gè)key就對應(yīng)于于一個(gè)"分桶"。要實(shí)現(xiàn)一個(gè)基于緩存分桶方案的高擴(kuò)展性的庫存系統(tǒng)，分桶的設(shè)計(jì)至關(guān)重要，比如一個(gè)熱點(diǎn)商品應(yīng)該對應(yīng)多少個(gè)分桶,分桶的數(shù)量能否根據(jù)當(dāng)前的業(yè)務(wù)變化做到彈性的伸縮

• 1、分桶預(yù)分配庫存：當(dāng)分桶初始化后，每個(gè)分桶應(yīng)該保存多少庫存量。不一定在預(yù)分配庫存階段將該商品的庫存數(shù)量從DB全部分配到緩存中，可能是一種漸進(jìn)式的分配策略，DB作為庫存總池子

• 2、分桶擴(kuò)容/縮容：分桶數(shù)量的變化，擴(kuò)縮容操作本質(zhì)上是調(diào)整桶映射管理內(nèi)的信息，加入或者減少桶，桶信息一旦增加或者減少了，扣減鏈路會(huì)秒級感知到，然后將用戶流量引導(dǎo)或者移除出去。從上面的DB架構(gòu)圖可以看出，比較簡單的實(shí)現(xiàn)方式就是根據(jù)當(dāng)前熱點(diǎn)商品的桶數(shù)量取模

• 3、桶內(nèi)庫存數(shù)量擴(kuò)容/縮容：即每個(gè)分桶內(nèi)該商品的庫存數(shù)量變化，擴(kuò)容場景主要用于當(dāng)該分桶內(nèi)庫存接近扣減完成時(shí)，系統(tǒng)自動(dòng)去MySQL庫存集群總池子里撈一部分過來放進(jìn)桶內(nèi)。縮容場景主要場景在于桶下線后將桶內(nèi)剩余的庫存回收到庫存總池子中

• 4、合并展示：在基于緩存的分桶設(shè)計(jì)中，由于同一種熱點(diǎn)商品拆分成了多個(gè)key，所以在前端界面展示上同樣會(huì)帶來挑戰(zhàn)，需要做庫存的合并

2、超賣問題

一個(gè)較為簡單的處理超賣問題的思路是預(yù)留一部分庫存，當(dāng)庫存數(shù)量低于之前定義的預(yù)留值時(shí)，直接返回前端庫存扣減完畢，從而避免造成超賣。

3、碎片問題

在一些類庫存系統(tǒng)的設(shè)計(jì)中，考慮到系統(tǒng)的兼容性和支持的扣減種類，或許扣減的是商品的庫存數(shù)量，或許是紅包的金額(將帶小數(shù)的紅包金額轉(zhuǎn)換成整型數(shù)扣減)。所謂碎片問題，舉個(gè)例子，假如扣減的是紅包金額，假設(shè)紅包金額至少要發(fā)1塊錢，換算成整型數(shù)也就是100，在多個(gè)分桶扣減的情況下，最后部分分桶的剩余庫存值可能低于100，而所有分桶加起來的總額又大于100。如果不做處理，就會(huì)造成資損。

應(yīng)對這種極端場景，系統(tǒng)需要在檢測到存在碎片時(shí)，自動(dòng)將存在碎片的分桶下線納入庫存總池子，由DB總池子再分出少量的緩存key來進(jìn)行扣減，多次循環(huán)直到不存在碎片為止?；蛘哚槍Τ霈F(xiàn)這種情況后，由于庫存總量已經(jīng)基本扣減完畢，在納入DB總池子后直接在DB側(cè)扣減。