高并發業務下的庫存扣減方案
扣減庫存需要查詢庫存是否足夠:
- 足夠就占用庫存
- 不夠則返回庫存不足（這里不區分庫存可用、占用、已消耗等狀態，統一成扣減庫存數量，簡化場景）
并發場景，若 查詢庫存和扣減庫存不具備原子性，就可能超賣，而高并發場景超賣概率會增高，超賣數額也會增高。處理超賣的確麻煩：
- 系統全鏈路刷數會很麻煩(多團隊協作)，客服外呼也有額外成本
- 最主要原因，客戶搶到訂單又被取消，嚴重影響客戶體驗，甚至引發客訴產生公關危機
實現邏輯
常用方案redis+lua，借助redis單線程執行+lua腳本中的邏輯，可在一次執行中順序完成的特性達到原子性（叫排它性更準確，因為不具備回滾動作，異常情況需自己手動編碼回滾）。
lua腳本基本實現
圖片
-- 1. 獲取庫存緩存key KYES[1] = hot_{itemCode-skuCode}_stock
local hot_item_stock = KYES[1]
-- 2. 獲取剩余庫存數量
local stock = tonumber(redis.call('get', hot_item_stock))
-- 3. 購買數量
local buy_qty = tonumber(ARGV[1])
-- 4. 如果庫存小于購買數量，則返回1，表達庫存不足
if stock < buy_qty then
return 1
end
-- 5. 庫存足夠，更新庫存數量
stock = stock - buy_qty
redis.call('set', hot_item_stock, tostring(stock))
-- 6. 扣減成功則返回2，表達庫存扣減成功
return 2但腳本還有一些問題：
- 不具備冪等性，同個訂單多次執行會導致重復扣減，手動回滾也無法判斷是否會回滾過，會出現重復增加的問題
- 不具備可追溯性，不知道庫存被誰被哪個訂單扣減了
增強后的lua腳本：
-- 1. 獲取庫存扣減記錄緩存 key KYES[2] = hot_{itemCode-skuCode}_deduction_history
local hot_deduction_history = KYES[2]
-- 2. 使用 Redis Cluster hash tag 保證 stock 和 history 在同一個槽
local exist = redis.call('hexists', hot_deduction_history, ARGV[2])
-- 3. 請求冪等判斷,存在返回0,表達已扣減過庫存
if exist == 1 then return 0 end
-- 4. 獲取庫存緩存key KYES[1] = hot_{itemCode-skuCode}_stock
local hot_item_stock = KYES[1]
-- 5. 獲取剩余庫存數量
local stock = tonumber(redis.call('get', hot_item_stock))
-- 6. 購買數量
local buy_qty = tonumber(ARGV[1])
-- 7. 如果庫存小于購買數量 則返回1,表達庫存不足
if stock < buy_qty then return 1 end
-- 8. 庫存足夠
-- 9. 1.更新庫存數量
-- 10. 2.插入扣減記錄 ARGV[2] = ${扣減請求唯一key} - ${扣減類型} 值為 buy_qty
stock = stock - buy_qty
redis.call('set', hot_item_stock, tostring(stock))
redis.call('hset', hot_deduction_history, ARGV[2], buy_qty)
-- 11. 如果剩余庫存等于0則返回2,表達庫存已為0
if stock == 0 then return 2 end
-- 12. 剩余庫存不為0返回 3 表達還有剩余庫存
return 3 end利用Redis Cluster hash tag保證stock和history在同個槽，這樣lua腳本才能正常執行。
★
因為正常要求 Lua 腳本操作的鍵必須在同一個 slot 中。
@Override
public <T, R> RFuture<R> evalReadAsync(String key, Codec codec, RedisCommand<T> evalCommandType, String script, List<Object> keys, Object... params) {
NodeSource source = getNodeSource(key);
return evalAsync(source, true, codec, evalCommandType, script, keys, false, params);
}
private NodeSource getNodeSource(String key) {
int slot = connectionManager.calcSlot(key);
return new NodeSource(slot);
}”
利用hot_deduction_history，判斷扣減請求是否執行過，以實現冪等性。
借助hot_deduction_history的V值判斷追溯扣減來源，如：用戶A的交易訂單A的扣減請求，或用戶B的借出單B的扣減請求。
回滾邏輯先判斷hot_deduction_history里有沒有 ${扣減請求唯一key}：
- 有，則執行回補邏輯
- 沒有，則認定回補成功
但該邏輯依舊有漏洞，如（消息亂序消費），訂單扣減庫存超時成功觸發了重新扣減庫存，但同時訂單取消觸發了庫存扣減回滾，回滾邏輯先成功，超時成功的重新扣減庫存就會成為臟數據留在redis里。
處理方案
有兩種：
- 追加對賬，定期校驗hot_deduction_history中數據對應單據的狀態，對于已經取消的單據追加一次回滾請求，存在時延（業務不一定接受）以及額外計算資源開銷
- 使用順序消息，讓扣減庫存、回滾庫存都走同一個MQ topic的有序隊列，借助MQ消息的有序性保證回滾動作一定在扣減動作后面執行，但有序串行必然帶來性能下降
高可用
Redis終究是內存，一旦服務中斷，數據就消失。所以需要追加保護數據不丟失的方案。
運用Redis部署的高可用方案：
- 采用Redis Cluster（數據分片+ 多副本 + 同步多寫 + 主從自動選舉）
- 多寫節點分（同城異地）多中心防止意外災害
定期歸檔冷數據。定期 + 庫存為0觸發redis數據往DB同步，流程如下：
圖片
CDC分發數據時，秒殺商品，hot_deduction_history的數據量不高，可以一次全量同步。但如果是普通大促商品，就需要再追加一個map動作分批處理，以保證每次執行CDC的數據量恒定，不至于一次性數據量太大出現OOM。代碼如下：
/**
* 對任務做分發
* @param stockKey 目標庫存的key值
*/
public void distribute(String stockKey) {
final String historyKey = StrUtil.format("hot_{}_deduction_history", stockKey);
// 獲取指定庫存key 所有扣減記錄的key(生產請分頁獲取，防止數據量太多)
final List<String> keys = RedisUtil.hkeys(historyKey, stockKey);
// 以 100 為大小，分片所有記錄key
final List<List<String>> splitKeys = CollUtil.split(keys, 100);
// 將集合分發給各個節點執行
map(historyKey, splitKeys);
}
/**
* 對單頁任務做執行
* @param historyKey 目標庫存的key值
* @param stockKeys 要執行的頁面大小
*/
public void mapExec(String historyKey, List<String> stockKeys) {
// 獲取指定庫存key 指定扣減記錄 的map
final Map<String, String> keys = RedisUtil.HmgetToMap(historyKey, stockKeys);
keys.entrySet()
.stream()
.map(stockRecordFactory::of)
.forEach(stockRecord -> {
// (冪等 + 去重) 扣減 + 保存記錄
stockConsumer.exec(stockRecord);
// 刪除redis中的 key 釋放空間
RedisUtil.hdel(historyKey, stockRecord.getRecordRedisKey());
});
}為啥不走DB
商品庫存數據在DB最終會落到單庫單表的一行數據。無法通過分庫分表提高請求的并行度。而在單節點場景，數據庫吞吐遠不如Redis。最基礎的原因：IO效率不是一個量級，DB是磁盤操作，而且還可能要多次讀盤，Redis是一步到位的內存操作。
同時，一般DB都是提交讀隔離級別，為保證原子性，執行庫存扣減，得加鎖，無論悲觀樂觀。不僅性能差（搶不到鎖要等待），而且因為非公平競爭，易出現線程饑餓。而redis是單線程操作，不存在共享變量競爭。
有些優化思路，如合并扣減，走批降低請求的并行連接數。但伴隨的集單的時延，以及按庫分批的訴求；還有拆庫存行，商品A100個庫存拆成2行商品A50庫存，然后扣減時分發請求，以提高并行連接數（多行可落在不同庫來提高并行連接數）。但伴隨的:
- 復雜的庫存行拆分管理（把什么庫存行在什么時候拆分到哪些庫）
- 部分庫存行超賣的問題（加鎖優化就又串行了，不加總量還有庫存，個別庫存行不足是允許一定系數超賣還是返回庫存不足就是一個要決策的問題）
部分頭部電商采用弱緩存抗讀（非庫存不足，不實時更新），DB抗寫的方案。該方案前提在于，通過一系列技術方案，流量落到庫存已相對低且平滑了（扛得住，不用再自己實現操作原子性）。
作者簡介：魔都架構師，多家大廠后端一線研發經驗，在分布式系統設計、數據平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社區頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統性能優化
- 活動&券等營銷中臺建設
- 交易平臺及數據中臺等架構和開發設計
- 車聯網核心平臺-物聯網連接平臺、大數據平臺架構設計及優化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大數據開發挖掘經驗
- 推薦系統項目
目前主攻市級軟件項目設計、構建服務全社會的應用系統。
參考：編程嚴選網
