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

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

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

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

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

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

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

熱點(diǎn)行更新

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

阿里巴巴PolarDB-X數(shù)據(jù)庫(kù)團(tuán)隊(duì)基于以上場(chǎng)景的需求，針對(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)電商庫(kù)存集群，資金平臺(tái)，權(quán)益發(fā)放平臺(tái)等核心數(shù)據(jù)庫(kù)集群。

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

類似原理，阿里云RDS數(shù)據(jù)庫(kù)團(tuán)隊(duì)同樣在內(nèi)核層面針對(duì)熱點(diǎn)行更新做了大量的優(yōu)化，核心思路為引入SQL語(yǔ)句的排隊(duì)機(jī)制，將可能存在行鎖沖突的語(yǔ)句放在一個(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)回滾。簡(jiǎn)單的使用范例如下

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)

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

基于緩存的分桶扣減方案

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

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

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

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

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

1、分桶管理

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

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

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

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

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

2、超賣問題

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

3、碎片問題

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

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