電商庫存系統的防超賣和高并發扣減方案

作者：京東云官方賬號 2022-09-19 09:49:17

首先 MCube 會依據模板緩存狀態判斷是否需要網絡獲取最新模板，當獲取到模板后進行模板加載，加載階段會將產物轉換為視圖樹的結構，轉換完成后將通過表達式引擎解析表達式并取得正確的值，通過事件解析引擎解析用戶自定義事件并完成事件的綁定，完成解析賦值以及事件綁定后進行視圖的渲染，最終將目標頁面展示到屏幕。

如果你要開發一個電商庫存系統，最擔心的是什么？閉上眼睛想下，當然是高并發和防超賣了！本文給出一個統籌考慮如何高并發和防超賣數據準確性的方案。讀者可以直接借鑒本設計，或在此基礎上做出更切合使用場景的設計。

背景

在今年的敏捷團隊建設中，我通過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

下面用電商庫存為示例，來說明如何高并發扣減庫存，原理同樣適用于其他需要并發寫和數據一致性的場景。

1.1 庫存數量模型示例

為了描述方便，下面使用簡化的庫存數量模型，真實場景中庫存數據項會比以下示例多很多，但已經夠說明原理。如下表，庫存數量表(stockNum)包含商品標識和庫存數量兩個字段，庫存數量代表有多少貨可以賣。

傳統通過數據庫保證不超賣

庫存管理的傳統方案為了保證不超賣，都是使用數據庫的事務來保證的：通過Sql判斷剩余的庫存數夠用，多個并發執行update語句只有一個能執行成功；為了保證扣減不重復，會配合一個防重表來防止重復的提交，做到冪等性，防重表示例（antiRe）設計如下：

比如一個下單過程的扣減過程示例如下：

事務開始
Insert into antiRe(code) value (‘訂單號+Sku’)
Update stockNum set num=num-下單數量 where skuId=商品ID and num-下單數量>0
事務結束

面臨系統流量越來越大，數據庫的性能瓶頸就會暴露出來：就算分庫分表也是沒用的，促銷的時候高并發都是針對少量商品的，最終并發流量會打向少數表，只能去提升單分片的抗量能力，所以接下來設計一種使用Redis緩存做庫存扣減的方案。

Redis緩存做庫存扣減的方案

理解，首先 MCube 會依據模板緩存狀態判斷是否需要網絡獲取最新模板，當獲取到模板后進行模板加載，加載階段會將產物轉換為視圖樹的結構，轉換完成后將通過表達式引擎解析表達式并取得正確的值，通過事件解析引擎解析用戶自定義事件并完成事件的綁定，完成解析賦值以及事件綁定后進行視圖的渲染，最終將目標頁面展示到屏幕。

2.1 綜合使用數據庫和Redis滿足高并發扣減的原理

扣減庫存其實包含兩個過程：第一步是超賣校驗，第二步是扣減數據的持久化；在傳統數據庫扣減中，兩步是一起完成的。抗寫的實現原理其實是巧妙的利用了分離的思想，分離開防超賣和數據持久化；首先防超賣是由Redis來完成的；通過Redis防超賣后，只要落庫就可以；落庫通過任務引擎，業務數據庫使用商品分庫分表，任務引擎任務通過單據號分庫分表，熱點商品的落庫會被狀態機分散開，消除熱點。

整體架構如下：

第一關解決超賣檢驗：可以把數據放入Redis中，每次扣減庫存，都對Redis中的數據進行incryby 扣減，如果返回的數量大于0，說明庫存夠，因為Redis是單線程，可以信任返回結果。第一關是Redis，可以抗高并發，性能Ok。超賣校驗通過后，進入第二關。

第二關解決庫存扣減：經過第一關后，第二關不需要再判斷數量是否足夠，只需要傻瓜扣減庫存就行，對數據庫執行如下語句,當然還是需要處理防重冪等的，不需要判斷數量是否大于0了，扣減SQL只要如下寫就可以。

事務開始
Insert into antiRe(code) value (‘訂單號+Sku’)
Update stockNum set num=num-下單數量 where skuId=商品ID
事務結束

要點：最終還是要使用數據庫，熱點怎么解決的呢？任務庫使用訂單號進行分庫分表，這樣針對同一個商品的不同訂單會散列在任務庫的不同庫存，雖然還是數據庫抗量，但已經消除了數據庫熱點。

整體交互序列圖如下：

2.2 熱點防刷

但Redis也是有瓶頸的，如果出現過熱SKU就會打向Redis單片，會造成單片性能抖動。庫存防刷有個前提是不能卡單的。可以定制設計JVM內毫秒級時間窗的限流，限流的目的是保護Redis,盡可能的不限流。限流的極端情況就是商品本來應該在一秒內賣完，但實際花了兩秒，正常并不會發生延遲銷售，之所以選擇JVM是因為如果采用遠端集中緩存限流，還未來得及收集數據就已經把Redis打死。

實現方案可以通過guava之類的框架，每10ms一個時間窗，每個時間窗進行計數，單臺服務器超過計數進行限流。比如10ms超過2個就限流，那么一秒一臺服務器就是200個，50臺服務器一秒就可以賣出1萬個貨，自己根據實際情況調整閾值就可以。

2.3 Redis扣減原理

Redis的incrby 命令可以用做庫存扣減，扣減項可能多個，使用Hash結構的hincrby命令，先用Reids原生命令模擬整個過程，為了簡化模型下面將演示一個數據項的操作，多個數據項原理完全等同。

127.0.0.1:6379> hset iphone inStock 1 #設置蘋果手機有一個可售庫存
(integer) 1
127.0.0.1:6379> hget iphone inStock   #查看蘋果手機可售庫存為1
"1"
127.0.0.1:6379> hincrby iphone inStock -1 #賣出扣減一個，返回剩余0，下單成功
(integer) 0
127.0.0.1:6379> hget iphone inStock #驗證剩余0
"0"
127.0.0.1:6379> hincrby iphone inStock -1 #應用并發超賣但Redis單線程返回剩余-1，下單失敗
(integer) -1
127.0.0.1:6379> hincrby iphone inStock 1 #識別-1，回滾庫存加一，剩余0
(integer) 0
127.0.0.1:6379> hget iphone inStock #庫存恢復正常
"0"

2.3.1 扣減的冪等性保證

如果應用調用Redis扣減后，不知道是否成功，可以針對批量扣減命令增加一個防重碼，對防重碼執行setnx命令，當發生異常的時候，可以根據防重碼是否存在來決定是否扣減成功，針對批量命名可以使用pipeline提高成功率。

// 初始化庫存
127.0.0.1:6379> hset iphone inStock 1 #設置蘋果手機有一個可售庫存
(integer) 1
127.0.0.1:6379> hget iphone inStock   #查看蘋果手機可售庫存為1
"1"
// 應用線程一扣減庫存，訂單號a100，jedis開啟pipeline
127.0.0.1:6379> set a100_iphone 
"1"
NX EX 10 #通過訂單號和商品防重碼
OK
127.0.0.1:6379> hincrby iphone inStock -1 #賣出扣減一個，返回剩余0，下單成功
(integer) 0
//結束pipeline，執行結果OK和0會一起返回

防止并發扣減后校驗：為了防止并發扣減，需要對Redis的hincrby命令返回值是否為負數，來判斷是否發生高并發超賣，如果扣減后的結果為負數，需要反向執行hincrby，把數據進行加回。

如果調用中發生網絡抖動，調用Redis超時，應用不知道操作結果，可以通過get命令來查看防重碼是否存在來判斷是否扣減成功。

127.0.0.1:6379> get a100_iphone   #扣減成功
"1"
127.0.0.1:6379> get a100_iphone   #扣減失敗
(nil)

2.3.2 單向保證

在很多場景中，因為沒有使用事務，你很難做到不超賣，并且不少賣，所以在極端情況下，可以選擇不超賣，但有可能少賣。當然還是應該盡量保證數據準確，不超賣，也不少賣；不能完全保證的前提下，選擇不超賣單向保證，也要通過手段來盡可能減少少賣的概率。

比如如果扣減Redis過程中，命令編排是先設置防重碼，再執行扣減命令失敗；如果執行過程網絡抖動可能放重碼成功，而扣減失敗，重試的時候就會認為已經成功，造成超賣，所以上面的命令順序是錯誤的，正確寫法應該是：

如果是扣減庫存，順序為：1.扣減庫存 2.寫入放重碼。

如果是回滾庫存，順序為：1.寫入放重碼 2.扣減庫存。

2.4 為什么使用Pipeline

在上面命令中，使用了Redis的Pipeline，來看下Pipeline的原理。

非pipeline模式

request-->執行-->responserequest-->執行-->response

pipeline模式

request-->執行 server將響應結果隊列化request-->執行 server將響應結果隊列化-->response-->response

使用Pipeline,能盡量保證多條命令返回結果的完整性，讀者可以考慮使用Redis事務來代替Pipeline，實際項目中，個人有過Pipeline的成功抗量經驗，并沒有使用Redis事務，正常情況下事務比pipeline慢一些，所以沒有采用。

Redis事務

1）mutil:開啟事務，此后的所有操作將被添加到當前鏈接事務的“操作隊列”中

2）exec:提交事務

3）discard:取消隊列執行

4）watch:如果watch的key被修改，觸發dicard。

2.5 通過任務引擎實現數據庫的最終一致性

前面通過任務引擎來保證數據一定持久化數據庫，「任務引擎」的設計如下，把任務調度抽象為業務無關的框架。「任務引擎」可以支持簡單的流程編排，并保證至少成功一次。「任務引擎」也可以作為狀態機的引擎出現，支持狀態機的調度，所以「任務引擎」也可以稱為「狀態機引擎」，在此文是同一個概念。

任務引擎設計核心原理：先把任務落庫，通過數據庫事務保證子任務拆分和父任務完成的事務一致性。

任務庫分庫分表：任務庫使用分庫分表，可以支撐水平擴展，通過設計分庫字段和業務庫字段不同，無數據熱點。

2.5.1 任務引擎的核心處理流程

第一步：同步調用提交任務，先把任務持久化到數據庫，狀態為「鎖定處理」，保證這件事一定得到處理。

注：原來的最初版本，任務落庫是待處理，然后由掃描Worker進行掃描，為了防止并發重復處理，掃描后進行單個任務鎖定，鎖定成功再進行處理。后來優化為落庫任務直接標識狀態為「鎖定處理」，是為了性能考慮，省去重新掃描再搶占任務，在進程內直接通過線程異步處理。

鎖定Sql參考：

UPDATE 任務表_分表號 SET 狀態 = 100,modifyTime = now() WHERE id = #{id} AND 狀態 = 0

第二步：異步線程調用外部處理過程，調用外部處理完成后，接收返回子任務列表。通過數據庫事務把父任務狀態設置為已經完成，子任務落庫。并把子任務加入線程池。

要點：保證子任務生成和父任務完成的事務性

第三步：子任務調度執行，并重新把新子任務落庫，如果沒有子任務返回，則整個流程結束。

異常處理Worker

異常解鎖Worker來把長時間未處理完成的任務解鎖，防止因為服務器重啟，或線程池滿造成的任務一直鎖定無服務器執行。

補漏Worker防止服務器重啟造成的線程池任務未執行完成，補漏程序重新鎖定，觸發執行。

任務狀態轉換過程

2.5.2 任務引擎數據庫設計

任務表數據庫結構設計示例（僅做示例使用，真實使用需要完善）

任務引擎數據庫容災

任務庫使用分庫分表，當一個庫宕機，可以把路由到宕機庫的流量重新散列到其他存活庫中，可以手工配置，或通過系統監控來自動化容災。如下圖，當任務庫2宕機后，可以通過修改配置，把任務庫2流量路由到任務庫1和3。補漏引擎繼續掃描任務庫2是因為當任務庫2通過主從容災恢復后，任務庫2宕機時未來的及處理的任務可以得到補充處理。