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

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

背景

在今年的敏捷團隊建設中，我透過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當機時未來的及處理的任務可以得到補充處理。

任務引擎排程舉例

比如使用者購買了兩個手機和一個電腦，手機和電腦分散在兩個資料庫，透過任務引擎先持久化任務，然後驅動拆分為兩個子任務，並最終保證兩個子任務一定成功，實現資料的最終一致性。整個執行過程的任務編排如下：

圖7 任務引擎排程舉例

任務引擎互動流程

圖8 任務引擎互動流程

總結

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

差異對比-異構資料的終極解決方案

只要有異構，一定會有差異的，為了保證差異的影響可控，終極方案還是要靠差異對比來解決。本文篇幅所限，不再展開，後續再單獨成文。DB和Redis差異對比的大概過程為：接收庫存變化訊息，不斷跟進對比Redis和DB的資料是否一致，如果連續穩定不一致，則進行資料修復，用DB資料來修改Redis的資料。

常見問題答疑

問：第一步超賣校驗Redis記憶體扣減，第二步扣減資料的持久化，中間斷了怎麼辦？(例：服務重啟)

答：如果是服務重啟，會在伺服器重啟之前停止這臺伺服器的服務；但此方案並不能保證資料的絕對一致，比如扣減redis後，應用伺服器故障直接當機，這種情況下的處理就需要更復雜的方案才能保證實時一致（目前沒有采取更復雜方案），可以透過另一個方案使用庫存資料和使用者的訂單資料進行資料比對修復，達到最終一致性。