計到高并發(fā)防超賣：Spring Boot庫存扣減體系完整實戰(zhàn))
做后端開發(fā)、電商系統(tǒng)或者進銷存系統(tǒng)時庫存模塊往往是繞不開的核心業(yè)務(wù)。很多項目初期“先做能跑的功能”到后面做秒殺、下單、退款時庫存扣減就開始出各種問題超賣、少賣、流水對不上、數(shù)據(jù)不一致。這篇文章會圍繞庫存管理這個業(yè)務(wù)場景從數(shù)據(jù)庫表設(shè)計、核心接口實現(xiàn)到高并發(fā)防超賣方案完整梳理一套可落地的庫存扣減體系。內(nèi)容包括完整DDL、Spring Boot核心代碼、Redis Lua腳本和常見排查思路適合初學(xué)后端、正在做畢設(shè)或負責(zé)訂單庫存模塊的開發(fā)者收藏備用。1. 庫存管理的核心概念1.1 庫存到底是什么從業(yè)務(wù)層面看庫存是“可銷售商品數(shù)量”的抽象。在數(shù)據(jù)庫里庫存通常不是一個簡單的數(shù)字而是由總庫存、鎖定庫存、可用庫存等字段共同表達的。很多新手容易把庫存理解成“一張表里一個數(shù)字”然后每次下單就執(zhí)行UPDATE inventory SET quantity quantity - 1 WHERE sku_id 1001;這種寫法在小流量、單機環(huán)境下勉強能運行但它缺少業(yè)務(wù)語義也無法應(yīng)對并發(fā)。真實業(yè)務(wù)里的庫存至少要區(qū)分三個口徑總庫存商品總共采購/入庫了多少件。鎖定庫存已經(jīng)預(yù)占但還沒完成支付的庫存比如用戶下單后待支付期間占用的庫存?？捎脦齑娈?dāng)前還能繼續(xù)被下單的庫存?？梢杂靡粋€簡單公式說明可用庫存 總庫存 - 鎖定庫存用戶下單后先把“可用庫存”減少、把“鎖定庫存”增加支付成功后再把“總庫存”和“鎖定庫存”同時扣減如果訂單取消則把鎖定庫存釋放可用庫存回補。這個流程相比“直接扣減總數(shù)”更嚴謹也是主流電商系統(tǒng)常用的庫存模型。1.2 常見的庫存業(yè)務(wù)模型在不同業(yè)務(wù)場景下庫存模型會有所差異。第一種是“現(xiàn)貨庫存模型”常見于電商、商城系統(tǒng)。商品入庫時增加總庫存用戶下單時先鎖定庫存支付后扣減總庫存取消訂單時回補庫存。這種模型需要考慮訂單超時釋放以及支付回調(diào)與庫存扣減的一致性。第二種是“備貨/預(yù)售模型”常見于倉配系統(tǒng)和供應(yīng)鏈系統(tǒng)。庫存不僅包含可售庫存還包含在途庫存、凍結(jié)庫存、質(zhì)檢庫存等。這類模型更復(fù)雜需要增加庫存狀態(tài)字段比如在途可售凍結(jié)鎖庫出庫中第三種是“門店/多倉庫存模型”需要把庫存按倉庫維度拆分每個倉庫都有自己的庫存表下單時還需要按倉庫計算可用庫存。這類模型在ERPSaaS系統(tǒng)里很常見核心表會帶warehouse_id這樣的倉庫維度。無論哪種模型底層都需要做到“扣減有依據(jù)、流水可追溯”這是庫存模塊設(shè)計的第一原則。1.3 庫存模塊在系統(tǒng)中的位置庫存模塊一般不獨立存在它和商品、訂單、支付、售后等模塊緊密關(guān)聯(lián)。典型調(diào)用鏈路如下商品詳情頁 - 查詢庫存 - 用戶下單 - 鎖定庫存 - 用戶支付 - 支付回調(diào) - 扣減庫存 - 發(fā)貨出庫 - 售后/取消 - 釋放庫存所以庫存接口不僅要考慮“當(dāng)前有沒有貨”還要和訂單狀態(tài)機聯(lián)動。這也意味著庫存模塊是一個需要強事務(wù)、強一致性、并發(fā)安全的模塊。如果庫存扣減失敗訂單不能創(chuàng)建如果取消訂單庫存必須回補。任何“先改訂單、再改庫存”的做法都要通過事務(wù)或者最終一致性機制保證兩邊不出現(xiàn)偏差。2. 環(huán)境準備與項目結(jié)構(gòu)2.1 技術(shù)棧選擇本文示例采用 Java Spring Boot 作為主技術(shù)棧數(shù)據(jù)庫使用 MySQLORM 使用 MyBatis Plus高并發(fā)示例使用 Redis Lua 腳本。這套組合在電商、企業(yè)后臺系統(tǒng)中非常常見資料多容易落地。技術(shù)環(huán)境如下版本需要根據(jù)你的項目實際情況調(diào)整JDK1.8 或 11如果使用 Spring Boot 3需要 JDK 17。Spring Boot2.7.x 或 3.x示例以 2.7.x 常見寫法為主。MySQL5.7 或 8.0推薦 8.0。MyBatis Plus3.5.x。Redis5.x / 6.x / 7.x 均可。開發(fā)工具IDEA Maven Postman 或 Apifox。這里說明一下代碼示例并不是版本寫死才能運行關(guān)鍵點是鎖庫存、扣庫存的 SQL 和事務(wù)邏輯你在自己的項目里可以按實際依賴調(diào)整。2.2 數(shù)據(jù)庫準備啟動 MySQL 后創(chuàng)建數(shù)據(jù)庫CREATE DATABASE IF NOT EXISTS inventory_demo DEFAULT CHARACTER SET utf8mb4; USE inventory_demo;建議使用 utf8mb4 字符集避免商品名或備注信息出現(xiàn)生僻字時寫入報錯。2.3 項目目錄結(jié)構(gòu)在 IDEA 中創(chuàng)建一個 Spring Boot 工程包名為com.example.inventory。核心目錄如下src/main/java/com/example/inventory ├── InventoryApplication.java ├── controller │ └── InventoryController.java ├── entity │ ├── Inventory.java │ └── InventoryFlow.java ├── mapper │ └── InventoryMapper.java └── service ├── InventoryService.java └── RedisInventoryService.java src/main/resources ├── application.yml └── lua/ ├── stock_deduct.lua └── stock_release.lua這是一份非常精簡的后端工程結(jié)構(gòu)實際項目中還會包含公共異常處理、統(tǒng)一返回結(jié)構(gòu)、配置類等考慮到教程篇幅本文只保留和庫存強相關(guān)的文件。3. 庫存表設(shè)計與數(shù)據(jù)模型3.1 商品表、庫存表與流水表設(shè)計先來看三張核心表的設(shè)計商品表、庫存表、庫存流水表。商品表比較簡單用于描述商品和SKU基本信息。CREATE TABLE product ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵, product_name VARCHAR(128) NOT NULL COMMENT 商品名稱, sku_code VARCHAR(64) NOT NULL COMMENT SKU編碼, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 售價, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_sku_code (sku_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;庫存表是核心表記錄每個SKU的總庫存、鎖定庫存、可用庫存和版本號。CREATE TABLE inventory ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵, sku_id BIGINT NOT NULL COMMENT 商品SKU ID, total_quantity INT NOT NULL DEFAULT 0 COMMENT 總庫存, locked_quantity INT NOT NULL DEFAULT 0 COMMENT 鎖定庫存, available_quantity INT NOT NULL DEFAULT 0 COMMENT 可用庫存, version INT NOT NULL DEFAULT 0 COMMENT 樂觀鎖版本號, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_sku_id (sku_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT庫存表;這里單獨加了一個version字段用來做樂觀鎖控制。在高并發(fā)場景下條件更新配合版本號能有效避免超賣。庫存流水表用于記錄每一次庫存變化方便對賬和排查。CREATE TABLE inventory_flow ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵, sku_id BIGINT NOT NULL COMMENT SKU ID, order_id VARCHAR(64) DEFAULT NULL COMMENT 訂單號, change_type TINYINT NOT NULL COMMENT 變化類型1-鎖定 2-扣減 3-釋放 4-入庫, quantity INT NOT NULL COMMENT 變化數(shù)量, before_quantity INT NOT NULL COMMENT 變化前可用庫存, after_quantity INT NOT NULL COMMENT 變化后可用庫存, remark VARCHAR(255) DEFAULT NULL COMMENT 備注, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_sku_id (sku_id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT庫存流水表;3.2 為什么需要庫存流水表很多小項目不建流水表只在庫存表上直接更新數(shù)量。剛開始問題不大但當(dāng)庫存數(shù)量異常、業(yè)務(wù)方質(zhì)疑“為什么少了一件”、運營要求“把某一筆扣減找出來”的時候沒有流水就會非常被動。庫存流水表是庫存模塊的“審計日志”。每次鎖定、釋放、扣減都要記錄變化的數(shù)量、變化前后的庫存、關(guān)聯(lián)訂單號和操作類型。有了這張表就可以通過訂單號反查操作鏈路也能在庫存不一致時通過流水重建現(xiàn)場。這里有個實踐建議流水表的數(shù)據(jù)量增長會很快建議定期歸檔或者按月份分表。查詢最近一個月的流水走熱表歷史流水走歸檔表。3.3 初始化數(shù)據(jù)插入一條商品和庫存測試數(shù)據(jù)INSERT INTO product (product_name, sku_code, price) VALUES (測試手機, SKU1001, 3999.00); INSERT INTO inventory (sku_id, total_quantity, locked_quantity, available_quantity, version) VALUES (1, 100, 0, 100, 0);這里總庫存 100鎖定庫存 0可用庫存 100版本號 0。4. 核心接口實現(xiàn)庫存查詢、預(yù)占、扣減與回補4.1 庫存查詢庫存查詢是最基礎(chǔ)、也最容易被忽略的接口。高并發(fā)下如果每次查詢都直接穿透數(shù)據(jù)庫會給數(shù)據(jù)庫帶來較大壓力所以生產(chǎn)環(huán)境通常會在庫存表前面加一層 Redis 緩存。先看數(shù)據(jù)庫查詢方式使用 MyBatis Plus 的 LambdaQueryWrapper// 文件路徑src/main/java/com/example/inventory/service/InventoryService.java Override public Inventory getInventoryBySkuId(Long skuId) { Inventory inventory inventoryMapper.selectOne( new LambdaQueryWrapperInventory() .eq(Inventory::getSkuId, skuId) ); if (inventory null) { throw new RuntimeException(SKU不存在); } return inventory; }如果使用 MyBatis 原生 Mapper也可以這樣寫Select(SELECT id, sku_id, total_quantity, locked_quantity, available_quantity, version FROM inventory WHERE sku_id #{skuId}) Inventory selectBySkuId(Param(skuId) Long skuId);這里需要注意selectOne方法要求查詢結(jié)果最多只有一條所以inventory表上必須保留sku_id的唯一索引。否則一旦出現(xiàn)重復(fù)數(shù)據(jù)查詢會直接拋異常。4.2 預(yù)占/鎖定庫存鎖定庫存是下單時最關(guān)鍵的一步。用戶點擊“提交訂單”后系統(tǒng)先鎖定指定數(shù)量的庫存防止其他用戶把庫存買走。這個階段還不能直接扣減總庫存因為用戶可能最終不支付。鎖定庫存的 SQL 使用條件更新保證“可用庫存足夠才更新”// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Update(UPDATE inventory SET locked_quantity locked_quantity #{quantity}, available_quantity available_quantity - #{quantity}, version version 1 WHERE sku_id #{skuId} AND available_quantity #{quantity} AND version #{version}) int lockInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity, Param(version) Integer version);這里加入available_quantity #{quantity}條件后即使并發(fā)請求同時到達數(shù)據(jù)庫也只會讓滿足條件的更新成功從源頭上杜絕超賣。Service 內(nèi)實現(xiàn)鎖定邏輯// 文件路徑src/main/java/com/example/inventory/service/InventoryService.java Transactional(rollbackFor Exception.class) public boolean lockStock(Long skuId, Integer quantity, String orderId) { Inventory inventory inventoryMapper.selectOne( new LambdaQueryWrapperInventory() .eq(Inventory::getSkuId, skuId) ); if (inventory null) { throw new RuntimeException(SKU不存在); } int rows inventoryMapper.lockInventory( skuId, quantity, inventory.getVersion() ); if (rows 0) { throw new RuntimeException(庫存不足或版本沖突請重試); } // 記錄庫存流水 saveFlow(skuId, orderId, 1, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() - quantity, 下單鎖定庫存); return true; }這個方法的執(zhí)行順序是先查一次庫存拿到當(dāng)前版本號然后執(zhí)行條件更新。如果更新影響行數(shù)不為 0說明扣減成功如果為 0說明在這期間庫存已經(jīng)被別人修改過或者可用庫存不足需要讓用戶重新確認庫存。4.3 扣減庫存用戶支付成功后系統(tǒng)需要把已經(jīng)鎖定的庫存真正扣減掉。此時不再檢查可用庫存只檢查鎖定庫存是否足夠。// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Update(UPDATE inventory SET total_quantity total_quantity - #{quantity}, locked_quantity locked_quantity - #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int deductInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity);這里為什么要同時扣減總庫存和鎖定庫存因為之前鎖定庫存時已經(jīng)把可用庫存減掉了總庫存沒有變化?，F(xiàn)在支付完成商品即將出庫所以總庫存也要同步減少同時把鎖定的額度釋放掉。對應(yīng)的 Service 方法Transactional(rollbackFor Exception.class) public boolean deductStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.deductInventory(skuId, quantity); if (rows 0) { throw new RuntimeException(鎖定庫存不足扣減失敗); } saveFlow(skuId, orderId, 2, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity(), 支付成功扣減庫存); return true; }這里流水中的變化前可用庫存和變化后可用庫存沒有變化因為鎖定庫存時已經(jīng)扣減了可用庫存扣減階段不再影響可用庫存。4.4 釋放/回補庫存訂單取消、超時未支付或售后退貨時需要把之前鎖定的庫存釋放回可用庫存。// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Update(UPDATE inventory SET locked_quantity locked_quantity - #{quantity}, available_quantity available_quantity #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int releaseInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity);釋放庫存時仍然要加條件locked_quantity #{quantity}避免因為業(yè)務(wù)重復(fù)取消、并發(fā)釋放導(dǎo)致鎖定庫存被扣成負數(shù)。Service 方法如下Transactional(rollbackFor Exception.class) public boolean releaseStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.releaseInventory(skuId, quantity); if (rows 0) { throw new RuntimeException(釋放庫存失敗鎖定庫存不足); } saveFlow(skuId, orderId, 3, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() quantity, 訂單取消釋放庫存); return true; }釋放庫存的流水里變化前可用庫存和變化后可用庫存都需要記錄方便核對回補的庫存是否準確。4.5 運行與驗證啟動項目后可以直接用 Postman 或 Apifox 測試接口。假設(shè)項目運行在8080端口鎖定庫存接口如下POST http://localhost:8080/inventory/lock Content-Type: application/json { skuId: 1, quantity: 2, orderId: ORDER20250115001 }返回成功并記錄一條庫存流水后再查詢庫存接口GET http://localhost:8080/inventory/get?skuId1預(yù)期返回總庫存 100鎖定庫存 2可用庫存 98版本號 1。如果連續(xù)使用同一版本號再次鎖定則因為版本沖突而失敗。這是樂觀鎖的一種典型表現(xiàn)。5. 高并發(fā)庫存扣減防超賣與并發(fā)控制5.1 為什么不能直接 update很多同學(xué)剛接觸庫存扣減時喜歡先寫查詢再寫更新Inventory inventory getBySkuId(skuId); if (inventory.getAvailableQuantity() quantity) { updateById(...); }這種“先查后改”在多線程并發(fā)下存在競態(tài)條件兩個請求同時查到可用庫存為 10同時判斷庫存足夠然后同時執(zhí)行扣減最終可能把庫存扣成負數(shù)造成超賣。即使在單體項目中也要盡量避免這種寫法。除非方法內(nèi)加鎖否則數(shù)據(jù)庫的隔離級別并不能阻止這種“讀-改-寫”的并發(fā)問題。正確做法是把庫存判斷和庫存扣減放在同一條UPDATE語句里讓數(shù)據(jù)庫通過行鎖和條件更新保證原子性。5.2 樂觀鎖方案樂觀鎖方案依賴版本號或時間戳。每次更新時比較當(dāng)前版本號如果版本號不匹配則更新失敗。核心 SQL 如下UPDATE inventory SET locked_quantity locked_quantity #{quantity}, available_quantity available_quantity - #{quantity}, version version 1 WHERE sku_id #{skuId} AND available_quantity #{quantity} AND version #{version};優(yōu)點適合并發(fā)沖突不嚴重的場景。實現(xiàn)簡單不需要額外加鎖。通過條件更新防止超賣。缺點高并發(fā)沖突時大量請求會更新失敗。需要業(yè)務(wù)層做重試或返回提示。如果你的項目并發(fā)量不是特別高可以先采用樂觀鎖方案。它能保證不超賣但對用戶體驗來說高峰期下單失敗率會偏高。5.3 悲觀鎖方案悲觀鎖使用數(shù)據(jù)庫的SELECT ... FOR UPDATE把庫存行鎖住然后判斷庫存并更新。Select(SELECT id, sku_id, total_quantity, locked_quantity, available_quantity, version FROM inventory WHERE sku_id #{skuId} FOR UPDATE) Inventory selectBySkuIdForUpdate(Param(skuId) Long skuId);然后 Service 中Transactional(rollbackFor Exception.class) public boolean lockStockWithPessimisticLock(Long skuId, Integer quantity, String orderId) { Inventory inventory inventoryMapper.selectBySkuIdForUpdate(skuId); if (inventory.getAvailableQuantity() quantity) { throw new RuntimeException(庫存不足); } int rows inventoryMapper.lockInventory(skuId, quantity, inventory.getVersion()); if (rows 0) { throw new RuntimeException(鎖定失敗); } saveFlow(...); return true; }注意FOR UPDATE必須在事務(wù)中才能生效。事務(wù)提交或回滾后釋放行鎖。悲觀鎖方案的特點強一致性不會因為并發(fā)沖突導(dǎo)致大量失敗。適合庫存熱點比較集中的場景。缺點是會阻塞其他事務(wù)降低吞吐量且對數(shù)據(jù)庫連接占用時間較長。在一些企業(yè)內(nèi)部 ERP、進銷存系統(tǒng)中因為并發(fā)量有限但數(shù)據(jù)一致性要求極高悲觀鎖反而是更簡單的方案。5.4 Redis Lua 預(yù)扣減方案當(dāng)并發(fā)量非常大比如秒殺場景數(shù)據(jù)庫壓力會非常大。這時可以把庫存預(yù)熱到 Redis通過 Lua 腳本原子地完成扣減判斷和扣減操作。Lua 腳本如下-- 文件路徑src/main/resources/lua/stock_deduct.lua local key KEYS[1] local quantity tonumber(ARGV[1]) local stock tonumber(redis.call(get, key)) if stock false then return -1 end if stock - quantity 0 then return 0 end redis.call(decrby, key, quantity) return 1釋放庫存的腳本-- 文件路徑src/main/resources/lua/stock_release.lua local key KEYS[1] local quantity tonumber(ARGV[1]) local stock tonumber(redis.call(get, key)) if stock false then return -1 end redis.call(incrby, key, quantity) return 1Java 調(diào)用示例// 文件路徑src/main/java/com/example/inventory/service/RedisInventoryService.java Service public class RedisInventoryService { Resource private StringRedisTemplate stringRedisTemplate; public static final String STOCK_KEY_PREFIX inventory:stock:; private DefaultRedisScriptLong buildDeductScript() { DefaultRedisScriptLong script new DefaultRedisScript(); script.setLocation(new ClassPathResource(lua/stock_deduct.lua)); script.setResultType(Long.class); return script; } public Long deductStockFromRedis(Long skuId, Integer quantity) { String key STOCK_KEY_PREFIX skuId; return stringRedisTemplate.execute( buildDeductScript(), Collections.singletonList(key), String.valueOf(quantity) ); } }這個方案把“判斷庫存是否充足”和“扣減庫存”放在同一個 Lua 腳本中Redis 會原子執(zhí)行整個腳本不會出現(xiàn)超賣。但要注意Redis 預(yù)扣減成功之后業(yè)務(wù)還沒有真正落庫。如果后續(xù)訂單創(chuàng)建失敗需要調(diào)用釋放腳本回補 Redis 庫存同時還要考慮到數(shù)據(jù)庫庫存最終扣減。這里有一個經(jīng)典的異步雙寫問題先更新 Redis再發(fā) MQ 消息異步扣減數(shù)據(jù)庫庫存如果 MQ 消費失敗則需要定時任務(wù)對賬。推薦的整體鏈路是請求進來先執(zhí)行 Redis Lua 扣減預(yù)庫存?？蹨p成功創(chuàng)建訂單發(fā)送“庫存扣減消息”。MQ 消費者收到消息后在數(shù)據(jù)庫事務(wù)中扣減真實庫存并記錄流水。如果數(shù)據(jù)庫扣減失敗則回補 Redis 庫存并記錄失敗日志。定時任務(wù)比對 Redis 庫存、數(shù)據(jù)庫庫存和流水發(fā)現(xiàn)不一致就告警并人工處理。這種方案結(jié)構(gòu)更復(fù)雜但能支撐較高的并發(fā)。5.5 消息隊列異步扣減通過消息隊列把同一個 SKU 的扣減請求串行化也是一種常見的防超賣方式。例如使用 RabbitMQ 或 RocketMQ訂單服務(wù)在下單時發(fā)送一條扣減消息消息里包含 SKU ID 和數(shù)量。消費端可以保證同一 SKU 的消息串行消費這樣即使服務(wù)層沒有加鎖數(shù)據(jù)庫也不會同時扣減同一個 SKU。這種方式適合削峰但會引入消息中間件增加架構(gòu)復(fù)雜度。訂單狀態(tài)下發(fā)后用戶要等待消息處理完成才能看到庫存結(jié)果。所以一般會和 Redis 預(yù)扣減配合使用而不是完全依賴消息隊列保證不超賣。6. 完整項目代碼示例為了讓整套邏輯更完整這里把核心代碼文件串起來。以下代碼基于 Spring Boot MyBatis Plus重點看庫存更新 SQL 與事務(wù)控制。6.1 pom.xml 依賴!-- 文件路徑pom.xml -- parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies注意不同 Spring Boot 版本對 MyBatis Plus 的兼容性不同。如果使用 Spring Boot 3需要把javax換成jakarta并選擇適配 Spring Boot 3 的 MyBatis Plus 版本。6.2 application.yml 配置# 文件路徑src/main/resources/application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/inventory_demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root redis: host: localhost port: 6379 database: 0 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0如果你的 MySQL 密碼、Redis 密碼與示例不同請改成自己的配置。map-underscore-to-camel-case: true可以讓數(shù)據(jù)庫字段sku_id自動映射到 Java 屬性skuId。6.3 啟動類與實體類// 文件路徑src/main/java/com/example/inventory/InventoryApplication.java SpringBootApplication MapperScan(com.example.inventory.mapper) public class InventoryApplication { public static void main(String[] args) { SpringApplication.run(InventoryApplication.class, args); } }// 文件路徑src/main/java/com/example/inventory/entity/Inventory.java Data TableName(inventory) public class Inventory { TableId(type IdType.AUTO) private Long id; private Long skuId; private Integer totalQuantity; private Integer lockedQuantity; private Integer availableQuantity; private Integer version; }// 文件路徑src/main/java/com/example/inventory/entity/InventoryFlow.java Data TableName(inventory_flow) public class InventoryFlow { TableId(type IdType.AUTO) private Long id; private Long skuId; private String orderId; private Integer changeType; private Integer quantity; private Integer beforeQuantity; private Integer afterQuantity; private String remark; }6.4 Mapper 接口// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Mapper public interface InventoryMapper extends BaseMapperInventory { Update(UPDATE inventory SET locked_quantity locked_quantity #{quantity}, available_quantity available_quantity - #{quantity}, version version 1 WHERE sku_id #{skuId} AND available_quantity #{quantity} AND version #{version}) int lockInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity, Param(version) Integer version); Update(UPDATE inventory SET total_quantity total_quantity - #{quantity}, locked_quantity locked_quantity - #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int deductInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity); Update(UPDATE inventory SET locked_quantity locked_quantity - #{quantity}, available_quantity available_quantity #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int releaseInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity); }這里不額外定義InventoryFlowMapper為了節(jié)省篇幅流水寫入在 Service 中通過insert方式完成。你也可以創(chuàng)建一個InventoryFlowMapper繼承BaseMapper。6.5 Service 完整實現(xiàn)// 文件路徑src/main/java/com/example/inventory/service/InventoryService.java Service public class InventoryService { Resource private InventoryMapper inventoryMapper; Transactional(rollbackFor Exception.class) public boolean lockStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.lockInventory(skuId, quantity, inventory.getVersion()); if (rows 0) { throw new RuntimeException(庫存不足或版本沖突請重試); } saveFlow(skuId, orderId, 1, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() - quantity, 下單鎖定庫存); return true; } Transactional(rollbackFor Exception.class) public boolean deductStock(Long skuId, Integer quantity, String orderId) { inventoryMapper.deductInventory(skuId, quantity); Inventory inventory getInventoryBySkuId(skuId); saveFlow(skuId, orderId, 2, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity(), 支付成功扣減庫存); return true; } Transactional(rollbackFor Exception.class) public boolean releaseStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.releaseInventory(skuId, quantity); if (rows 0) { throw new RuntimeException(釋放庫存失敗); } saveFlow(skuId, orderId, 3, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() quantity, 訂單取消釋放庫存); return true; } public Inventory getInventoryBySkuId(Long skuId) { Inventory inventory inventoryMapper.selectOne( new LambdaQueryWrapperInventory() .eq(Inventory::getSkuId, skuId) ); if (inventory null) { throw new RuntimeException(SKU不存在); } return inventory; } private void saveFlow(Long skuId, String orderId, Integer changeType, Integer quantity, Integer beforeQuantity, Integer afterQuantity, String remark) { InventoryFlow flow new InventoryFlow(); flow.setSkuId(skuId); flow.setOrderId(orderId); flow.setChangeType(changeType); flow.setQuantity(quantity); flow.setBeforeQuantity(beforeQuantity); flow.setAfterQuantity(afterQuantity); flow.setRemark(remark); inventoryFlowMapper.insert(flow); } }如果你的項目沒有注入InventoryFlowMapper記得在 Service 中補充定義Resource private InventoryFlowMapper inventoryFlowMapper;并且創(chuàng)建對應(yīng)的 Mapper// 文件路徑src/main/java/com/example/inventory/mapper/InventoryFlowMapper.java Mapper public interface InventoryFlowMapper extends BaseMapperInventoryFlow { }6.6 Controller 示例// 文件路徑src/main/java/com/example/inventory/controller/InventoryController.java RestController RequestMapping(/inventory) public class InventoryController { Resource private InventoryService inventoryService; GetMapping(/get) public Inventory getInventory(Long skuId) { return inventoryService.getInventoryBySkuId(skuId); } PostMapping(/lock) public String lock(RequestBody LockRequest request) { inventoryService.lockStock(request.getSkuId(), request.getQuantity(), request.getOrderId()); return success; } PostMapping(/deduct) public String deduct(RequestBody LockRequest request) { inventoryService.deductStock(request.getSkuId(), request.getQuantity(), request.getOrderId()); return success; } PostMapping(/release) public String release(RequestBody LockRequest request) { inventoryService.releaseStock(request.getSkuId(), request.getQuantity(), request.getOrderId()); return success; } Data public static class LockRequest { private Long skuId; private Integer quantity; private String orderId; } }到這里一套基于數(shù)據(jù)庫事務(wù)條件的庫存閉合鏈路已經(jīng)跑通。你可以把項目啟動后按照 4.5 中的請求示例測試。7. 常見問題與排查思路在實際開發(fā)中庫存模塊的高頻問題往往不是代碼寫不出來而是并發(fā)或者數(shù)據(jù)一致性出問題。下面整理了一份排查清單。問題現(xiàn)象常見原因解決思路庫存扣成負數(shù)先查庫存再更新沒有原子條件使用條件更新available_quantity quantity樂觀鎖沖突導(dǎo)致下單失敗并發(fā)高版本號頻繁不匹配增加重試機制或切換悲觀鎖/Redis Lua鎖定庫存后訂單未支付庫存不釋放沒有超時釋放機制增加訂單超時自動取消任務(wù)并調(diào)用釋放庫存接口Redis 預(yù)扣減成功但數(shù)據(jù)庫庫存最終沒扣MQ 消費失敗或漏發(fā)消息增加定時對賬用流水表比對待扣減記錄庫存流水與庫存表不一致更新庫存和寫入流水不在同一事務(wù)確保庫存更新、流水插入在同一個Transactional內(nèi)重復(fù)扣減庫存接口沒有做冪等控制使用訂單號或業(yè)務(wù)單號做唯一索引重復(fù)請求直接拒絕查詢庫存很慢缺少索引或全表掃描為sku_id建唯一索引流水表建order_id/sku_id索引同一 SKU 并發(fā)下單時吞吐量低使用行鎖或悲觀鎖阻塞使用 Redis 預(yù)扣減 MQ 異步落庫如果遇到庫存異常建議排查順序如下查庫存流水找對應(yīng)order_id下的變更記錄。對比流水中before_quantity和after_quantity確認變化量是否連續(xù)。查 Redis 當(dāng)前庫存和數(shù)據(jù)庫庫存看兩者是否一致。查服務(wù)日志重點看數(shù)據(jù)庫更新影響行數(shù)是否為 0。如果發(fā)現(xiàn)流水缺失檢查事務(wù)是否回滾或者是否繞過了庫存服務(wù)直接更新數(shù)據(jù)庫。8. 最佳實踐與工程建議做完一個基礎(chǔ)庫存模塊后想在項目里真正穩(wěn)定運行還需要注意下面這些工程問題。第一所有庫存變更必須走同一個庫存服務(wù)。很多系統(tǒng)出現(xiàn)庫存不一致是因為不同模塊各寫各的UPDATE inventory語句。有的在訂單服務(wù)扣有的在售后服務(wù)扣有的直接在 DB 管理工具里手工改。建議所有庫存操作都收斂到獨立的 inventory 服務(wù)或獨立 Service 中方便統(tǒng)一加鎖、統(tǒng)一寫流水、統(tǒng)一監(jiān)控。第二庫存流水要設(shè)置唯一約束和冪等鍵。比如用order_id change_type sku_id作為業(yè)務(wù)冪等鍵防止消息重復(fù)消費、接口重試導(dǎo)致重復(fù)扣減?？梢越oinventory_flow增加唯一索引ALTER TABLE inventory_flow ADD UNIQUE KEY uk_order_change_sku (order_id, change_type, sku_id);第三庫存表更新時盡量使用行級條件更新避免“查出來再判斷”的寫法。哪怕只是簡單扣減也要習(xí)慣把庫存充足條件寫到 SQL 的WHERE中。第四引入 Redis 后要考慮緩存與數(shù)據(jù)庫的一致性問題。建議采用以下策略啟動或運營編輯庫存后主動刷新 Redis 庫存。Redis 庫存設(shè)置合理過期時間比如 30 分鐘過期后回源數(shù)據(jù)庫。每次數(shù)據(jù)庫庫存扣減成功后刪除 Redis 緩存讓下一次讀取重新加載。定時任務(wù)每 5 分鐘掃描 Redis 庫存和數(shù)據(jù)庫庫存差異異常時告警。第五庫存扣減失敗一定要有明確的錯誤碼。不要說“系統(tǒng)繁忙”至少區(qū)分庫存不足商品不存在重復(fù)操作庫存服務(wù)超時這樣前端和客戶端才能做差異化提示。第六生產(chǎn)環(huán)境中的庫存調(diào)整必須走審批和審計。運營手工調(diào)整庫存是風(fēng)險很高的操作建議提供獨立的管理端接口操作記錄寫入操作日志并且不能直接連數(shù)據(jù)庫修改業(yè)務(wù)表。第七事務(wù)超時和數(shù)據(jù)庫連接需要注意。悲觀鎖方案中如果事務(wù)內(nèi)有遠程調(diào)用很容易出現(xiàn)長事務(wù)。建議庫存事務(wù)內(nèi)只做數(shù)據(jù)庫操作不要嵌套外部 HTTP 請求。遠程調(diào)用放在事務(wù)提交后再執(zhí)行。9. 總結(jié)與學(xué)習(xí)路線本文圍繞庫存管理完整梳理了從數(shù)據(jù)模型、表設(shè)計到庫存鎖定、扣減、釋放的落地流程也分析了樂觀鎖、悲觀鎖、Redis Lua 預(yù)扣減和 MQ 異步消峰幾種主流并發(fā)方案。你可以根據(jù)項目規(guī)模選擇合適的方案中小系統(tǒng)先用數(shù)據(jù)庫條件更新即可高并發(fā)場景再逐步引入 Redis 和消息隊列。接下來可以繼續(xù)學(xué)習(xí)這些方向訂單超時自動取消結(jié)合延遲消息或定時任務(wù)釋放庫存。庫存對賬系統(tǒng)通過流水表每日核對訂單與庫存數(shù)據(jù)。分布式事務(wù)跨服務(wù)和跨庫時如何保證庫存與訂單一致。多倉庫庫存在庫存模型中增加倉庫維度做倉配庫存管理。庫存盤點結(jié)合 Redis 和數(shù)據(jù)庫實現(xiàn)高并發(fā)盤點邏輯。在實際項目中不建議一上來就堆 Redis、MQ、分布式事務(wù)。先把單庫事務(wù)版本的庫存鏈路跑通再把 Redis 預(yù)扣減引入熱點商品最后根據(jù)業(yè)務(wù)體量決定是否引入異步隊列。這種循序漸進的方式更容易排查問題也更容易保證系統(tǒng)穩(wěn)定。如果這篇文章對你有幫助可以收藏備用。下次遇到庫存超賣、鎖庫存失敗或者流水對不上時按照本文的思路一步步排查大多數(shù)問題都能快速定位。 從表設(shè)計到高并發(fā)防超賣：Spring Boot庫存扣減體系完整實戰(zhàn)
做后端開發(fā)、電商系統(tǒng)或者進銷存系統(tǒng)時庫存模塊往往是繞不開的核心業(yè)務(wù)。很多項目初期“先做能跑的功能”到后面做秒殺、下單、退款時庫存扣減就開始出各種問題超賣、少賣、流水對不上、數(shù)據(jù)不一致。這篇文章會圍繞庫存管理這個業(yè)務(wù)場景從數(shù)據(jù)庫表設(shè)計、核心接口實現(xiàn)到高并發(fā)防超賣方案完整梳理一套可落地的庫存扣減體系。內(nèi)容包括完整DDL、Spring Boot核心代碼、Redis Lua腳本和常見排查思路適合初學(xué)后端、正在做畢設(shè)或負責(zé)訂單庫存模塊的開發(fā)者收藏備用。1. 庫存管理的核心概念1.1 庫存到底是什么從業(yè)務(wù)層面看庫存是“可銷售商品數(shù)量”的抽象。在數(shù)據(jù)庫里庫存通常不是一個簡單的數(shù)字而是由總庫存、鎖定庫存、可用庫存等字段共同表達的。很多新手容易把庫存理解成“一張表里一個數(shù)字”然后每次下單就執(zhí)行UPDATE inventory SET quantity quantity - 1 WHERE sku_id 1001;這種寫法在小流量、單機環(huán)境下勉強能運行但它缺少業(yè)務(wù)語義也無法應(yīng)對并發(fā)。真實業(yè)務(wù)里的庫存至少要區(qū)分三個口徑總庫存商品總共采購/入庫了多少件。鎖定庫存已經(jīng)預(yù)占但還沒完成支付的庫存比如用戶下單后待支付期間占用的庫存?？捎脦齑娈?dāng)前還能繼續(xù)被下單的庫存?？梢杂靡粋€簡單公式說明可用庫存 總庫存 - 鎖定庫存用戶下單后先把“可用庫存”減少、把“鎖定庫存”增加支付成功后再把“總庫存”和“鎖定庫存”同時扣減如果訂單取消則把鎖定庫存釋放可用庫存回補。這個流程相比“直接扣減總數(shù)”更嚴謹也是主流電商系統(tǒng)常用的庫存模型。1.2 常見的庫存業(yè)務(wù)模型在不同業(yè)務(wù)場景下庫存模型會有所差異。第一種是“現(xiàn)貨庫存模型”常見于電商、商城系統(tǒng)。商品入庫時增加總庫存用戶下單時先鎖定庫存支付后扣減總庫存取消訂單時回補庫存。這種模型需要考慮訂單超時釋放以及支付回調(diào)與庫存扣減的一致性。第二種是“備貨/預(yù)售模型”常見于倉配系統(tǒng)和供應(yīng)鏈系統(tǒng)。庫存不僅包含可售庫存還包含在途庫存、凍結(jié)庫存、質(zhì)檢庫存等。這類模型更復(fù)雜需要增加庫存狀態(tài)字段比如在途可售凍結(jié)鎖庫出庫中第三種是“門店/多倉庫存模型”需要把庫存按倉庫維度拆分每個倉庫都有自己的庫存表下單時還需要按倉庫計算可用庫存。這類模型在ERPSaaS系統(tǒng)里很常見核心表會帶warehouse_id這樣的倉庫維度。無論哪種模型底層都需要做到“扣減有依據(jù)、流水可追溯”這是庫存模塊設(shè)計的第一原則。1.3 庫存模塊在系統(tǒng)中的位置庫存模塊一般不獨立存在它和商品、訂單、支付、售后等模塊緊密關(guān)聯(lián)。典型調(diào)用鏈路如下商品詳情頁 - 查詢庫存 - 用戶下單 - 鎖定庫存 - 用戶支付 - 支付回調(diào) - 扣減庫存 - 發(fā)貨出庫 - 售后/取消 - 釋放庫存所以庫存接口不僅要考慮“當(dāng)前有沒有貨”還要和訂單狀態(tài)機聯(lián)動。這也意味著庫存模塊是一個需要強事務(wù)、強一致性、并發(fā)安全的模塊。如果庫存扣減失敗訂單不能創(chuàng)建如果取消訂單庫存必須回補。任何“先改訂單、再改庫存”的做法都要通過事務(wù)或者最終一致性機制保證兩邊不出現(xiàn)偏差。2. 環(huán)境準備與項目結(jié)構(gòu)2.1 技術(shù)棧選擇本文示例采用 Java Spring Boot 作為主技術(shù)棧數(shù)據(jù)庫使用 MySQLORM 使用 MyBatis Plus高并發(fā)示例使用 Redis Lua 腳本。這套組合在電商、企業(yè)后臺系統(tǒng)中非常常見資料多容易落地。技術(shù)環(huán)境如下版本需要根據(jù)你的項目實際情況調(diào)整JDK1.8 或 11如果使用 Spring Boot 3需要 JDK 17。Spring Boot2.7.x 或 3.x示例以 2.7.x 常見寫法為主。MySQL5.7 或 8.0推薦 8.0。MyBatis Plus3.5.x。Redis5.x / 6.x / 7.x 均可。開發(fā)工具IDEA Maven Postman 或 Apifox。這里說明一下代碼示例并不是版本寫死才能運行關(guān)鍵點是鎖庫存、扣庫存的 SQL 和事務(wù)邏輯你在自己的項目里可以按實際依賴調(diào)整。2.2 數(shù)據(jù)庫準備啟動 MySQL 后創(chuàng)建數(shù)據(jù)庫CREATE DATABASE IF NOT EXISTS inventory_demo DEFAULT CHARACTER SET utf8mb4; USE inventory_demo;建議使用 utf8mb4 字符集避免商品名或備注信息出現(xiàn)生僻字時寫入報錯。2.3 項目目錄結(jié)構(gòu)在 IDEA 中創(chuàng)建一個 Spring Boot 工程包名為com.example.inventory。核心目錄如下src/main/java/com/example/inventory ├── InventoryApplication.java ├── controller │ └── InventoryController.java ├── entity │ ├── Inventory.java │ └── InventoryFlow.java ├── mapper │ └── InventoryMapper.java └── service ├── InventoryService.java └── RedisInventoryService.java src/main/resources ├── application.yml └── lua/ ├── stock_deduct.lua └── stock_release.lua這是一份非常精簡的后端工程結(jié)構(gòu)實際項目中還會包含公共異常處理、統(tǒng)一返回結(jié)構(gòu)、配置類等考慮到教程篇幅本文只保留和庫存強相關(guān)的文件。3. 庫存表設(shè)計與數(shù)據(jù)模型3.1 商品表、庫存表與流水表設(shè)計先來看三張核心表的設(shè)計商品表、庫存表、庫存流水表。商品表比較簡單用于描述商品和SKU基本信息。CREATE TABLE product ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵, product_name VARCHAR(128) NOT NULL COMMENT 商品名稱, sku_code VARCHAR(64) NOT NULL COMMENT SKU編碼, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 售價, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_sku_code (sku_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;庫存表是核心表記錄每個SKU的總庫存、鎖定庫存、可用庫存和版本號。CREATE TABLE inventory ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵, sku_id BIGINT NOT NULL COMMENT 商品SKU ID, total_quantity INT NOT NULL DEFAULT 0 COMMENT 總庫存, locked_quantity INT NOT NULL DEFAULT 0 COMMENT 鎖定庫存, available_quantity INT NOT NULL DEFAULT 0 COMMENT 可用庫存, version INT NOT NULL DEFAULT 0 COMMENT 樂觀鎖版本號, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_sku_id (sku_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT庫存表;這里單獨加了一個version字段用來做樂觀鎖控制。在高并發(fā)場景下條件更新配合版本號能有效避免超賣。庫存流水表用于記錄每一次庫存變化方便對賬和排查。CREATE TABLE inventory_flow ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵, sku_id BIGINT NOT NULL COMMENT SKU ID, order_id VARCHAR(64) DEFAULT NULL COMMENT 訂單號, change_type TINYINT NOT NULL COMMENT 變化類型1-鎖定 2-扣減 3-釋放 4-入庫, quantity INT NOT NULL COMMENT 變化數(shù)量, before_quantity INT NOT NULL COMMENT 變化前可用庫存, after_quantity INT NOT NULL COMMENT 變化后可用庫存, remark VARCHAR(255) DEFAULT NULL COMMENT 備注, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_sku_id (sku_id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT庫存流水表;3.2 為什么需要庫存流水表很多小項目不建流水表只在庫存表上直接更新數(shù)量。剛開始問題不大但當(dāng)庫存數(shù)量異常、業(yè)務(wù)方質(zhì)疑“為什么少了一件”、運營要求“把某一筆扣減找出來”的時候沒有流水就會非常被動。庫存流水表是庫存模塊的“審計日志”。每次鎖定、釋放、扣減都要記錄變化的數(shù)量、變化前后的庫存、關(guān)聯(lián)訂單號和操作類型。有了這張表就可以通過訂單號反查操作鏈路也能在庫存不一致時通過流水重建現(xiàn)場。這里有個實踐建議流水表的數(shù)據(jù)量增長會很快建議定期歸檔或者按月份分表。查詢最近一個月的流水走熱表歷史流水走歸檔表。3.3 初始化數(shù)據(jù)插入一條商品和庫存測試數(shù)據(jù)INSERT INTO product (product_name, sku_code, price) VALUES (測試手機, SKU1001, 3999.00); INSERT INTO inventory (sku_id, total_quantity, locked_quantity, available_quantity, version) VALUES (1, 100, 0, 100, 0);這里總庫存 100鎖定庫存 0可用庫存 100版本號 0。4. 核心接口實現(xiàn)庫存查詢、預(yù)占、扣減與回補4.1 庫存查詢庫存查詢是最基礎(chǔ)、也最容易被忽略的接口。高并發(fā)下如果每次查詢都直接穿透數(shù)據(jù)庫會給數(shù)據(jù)庫帶來較大壓力所以生產(chǎn)環(huán)境通常會在庫存表前面加一層 Redis 緩存。先看數(shù)據(jù)庫查詢方式使用 MyBatis Plus 的 LambdaQueryWrapper// 文件路徑src/main/java/com/example/inventory/service/InventoryService.java Override public Inventory getInventoryBySkuId(Long skuId) { Inventory inventory inventoryMapper.selectOne( new LambdaQueryWrapperInventory() .eq(Inventory::getSkuId, skuId) ); if (inventory null) { throw new RuntimeException(SKU不存在); } return inventory; }如果使用 MyBatis 原生 Mapper也可以這樣寫Select(SELECT id, sku_id, total_quantity, locked_quantity, available_quantity, version FROM inventory WHERE sku_id #{skuId}) Inventory selectBySkuId(Param(skuId) Long skuId);這里需要注意selectOne方法要求查詢結(jié)果最多只有一條所以inventory表上必須保留sku_id的唯一索引。否則一旦出現(xiàn)重復(fù)數(shù)據(jù)查詢會直接拋異常。4.2 預(yù)占/鎖定庫存鎖定庫存是下單時最關(guān)鍵的一步。用戶點擊“提交訂單”后系統(tǒng)先鎖定指定數(shù)量的庫存防止其他用戶把庫存買走。這個階段還不能直接扣減總庫存因為用戶可能最終不支付。鎖定庫存的 SQL 使用條件更新保證“可用庫存足夠才更新”// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Update(UPDATE inventory SET locked_quantity locked_quantity #{quantity}, available_quantity available_quantity - #{quantity}, version version 1 WHERE sku_id #{skuId} AND available_quantity #{quantity} AND version #{version}) int lockInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity, Param(version) Integer version);這里加入available_quantity #{quantity}條件后即使并發(fā)請求同時到達數(shù)據(jù)庫也只會讓滿足條件的更新成功從源頭上杜絕超賣。Service 內(nèi)實現(xiàn)鎖定邏輯// 文件路徑src/main/java/com/example/inventory/service/InventoryService.java Transactional(rollbackFor Exception.class) public boolean lockStock(Long skuId, Integer quantity, String orderId) { Inventory inventory inventoryMapper.selectOne( new LambdaQueryWrapperInventory() .eq(Inventory::getSkuId, skuId) ); if (inventory null) { throw new RuntimeException(SKU不存在); } int rows inventoryMapper.lockInventory( skuId, quantity, inventory.getVersion() ); if (rows 0) { throw new RuntimeException(庫存不足或版本沖突請重試); } // 記錄庫存流水 saveFlow(skuId, orderId, 1, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() - quantity, 下單鎖定庫存); return true; }這個方法的執(zhí)行順序是先查一次庫存拿到當(dāng)前版本號然后執(zhí)行條件更新。如果更新影響行數(shù)不為 0說明扣減成功如果為 0說明在這期間庫存已經(jīng)被別人修改過或者可用庫存不足需要讓用戶重新確認庫存。4.3 扣減庫存用戶支付成功后系統(tǒng)需要把已經(jīng)鎖定的庫存真正扣減掉。此時不再檢查可用庫存只檢查鎖定庫存是否足夠。// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Update(UPDATE inventory SET total_quantity total_quantity - #{quantity}, locked_quantity locked_quantity - #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int deductInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity);這里為什么要同時扣減總庫存和鎖定庫存因為之前鎖定庫存時已經(jīng)把可用庫存減掉了總庫存沒有變化?，F(xiàn)在支付完成商品即將出庫所以總庫存也要同步減少同時把鎖定的額度釋放掉。對應(yīng)的 Service 方法Transactional(rollbackFor Exception.class) public boolean deductStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.deductInventory(skuId, quantity); if (rows 0) { throw new RuntimeException(鎖定庫存不足扣減失敗); } saveFlow(skuId, orderId, 2, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity(), 支付成功扣減庫存); return true; }這里流水中的變化前可用庫存和變化后可用庫存沒有變化因為鎖定庫存時已經(jīng)扣減了可用庫存扣減階段不再影響可用庫存。4.4 釋放/回補庫存訂單取消、超時未支付或售后退貨時需要把之前鎖定的庫存釋放回可用庫存。// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Update(UPDATE inventory SET locked_quantity locked_quantity - #{quantity}, available_quantity available_quantity #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int releaseInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity);釋放庫存時仍然要加條件locked_quantity #{quantity}避免因為業(yè)務(wù)重復(fù)取消、并發(fā)釋放導(dǎo)致鎖定庫存被扣成負數(shù)。Service 方法如下Transactional(rollbackFor Exception.class) public boolean releaseStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.releaseInventory(skuId, quantity); if (rows 0) { throw new RuntimeException(釋放庫存失敗鎖定庫存不足); } saveFlow(skuId, orderId, 3, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() quantity, 訂單取消釋放庫存); return true; }釋放庫存的流水里變化前可用庫存和變化后可用庫存都需要記錄方便核對回補的庫存是否準確。4.5 運行與驗證啟動項目后可以直接用 Postman 或 Apifox 測試接口。假設(shè)項目運行在8080端口鎖定庫存接口如下POST http://localhost:8080/inventory/lock Content-Type: application/json { skuId: 1, quantity: 2, orderId: ORDER20250115001 }返回成功并記錄一條庫存流水后再查詢庫存接口GET http://localhost:8080/inventory/get?skuId1預(yù)期返回總庫存 100鎖定庫存 2可用庫存 98版本號 1。如果連續(xù)使用同一版本號再次鎖定則因為版本沖突而失敗。這是樂觀鎖的一種典型表現(xiàn)。5. 高并發(fā)庫存扣減防超賣與并發(fā)控制5.1 為什么不能直接 update很多同學(xué)剛接觸庫存扣減時喜歡先寫查詢再寫更新Inventory inventory getBySkuId(skuId); if (inventory.getAvailableQuantity() quantity) { updateById(...); }這種“先查后改”在多線程并發(fā)下存在競態(tài)條件兩個請求同時查到可用庫存為 10同時判斷庫存足夠然后同時執(zhí)行扣減最終可能把庫存扣成負數(shù)造成超賣。即使在單體項目中也要盡量避免這種寫法。除非方法內(nèi)加鎖否則數(shù)據(jù)庫的隔離級別并不能阻止這種“讀-改-寫”的并發(fā)問題。正確做法是把庫存判斷和庫存扣減放在同一條UPDATE語句里讓數(shù)據(jù)庫通過行鎖和條件更新保證原子性。5.2 樂觀鎖方案樂觀鎖方案依賴版本號或時間戳。每次更新時比較當(dāng)前版本號如果版本號不匹配則更新失敗。核心 SQL 如下UPDATE inventory SET locked_quantity locked_quantity #{quantity}, available_quantity available_quantity - #{quantity}, version version 1 WHERE sku_id #{skuId} AND available_quantity #{quantity} AND version #{version};優(yōu)點適合并發(fā)沖突不嚴重的場景。實現(xiàn)簡單不需要額外加鎖。通過條件更新防止超賣。缺點高并發(fā)沖突時大量請求會更新失敗。需要業(yè)務(wù)層做重試或返回提示。如果你的項目并發(fā)量不是特別高可以先采用樂觀鎖方案。它能保證不超賣但對用戶體驗來說高峰期下單失敗率會偏高。5.3 悲觀鎖方案悲觀鎖使用數(shù)據(jù)庫的SELECT ... FOR UPDATE把庫存行鎖住然后判斷庫存并更新。Select(SELECT id, sku_id, total_quantity, locked_quantity, available_quantity, version FROM inventory WHERE sku_id #{skuId} FOR UPDATE) Inventory selectBySkuIdForUpdate(Param(skuId) Long skuId);然后 Service 中Transactional(rollbackFor Exception.class) public boolean lockStockWithPessimisticLock(Long skuId, Integer quantity, String orderId) { Inventory inventory inventoryMapper.selectBySkuIdForUpdate(skuId); if (inventory.getAvailableQuantity() quantity) { throw new RuntimeException(庫存不足); } int rows inventoryMapper.lockInventory(skuId, quantity, inventory.getVersion()); if (rows 0) { throw new RuntimeException(鎖定失敗); } saveFlow(...); return true; }注意FOR UPDATE必須在事務(wù)中才能生效。事務(wù)提交或回滾后釋放行鎖。悲觀鎖方案的特點強一致性不會因為并發(fā)沖突導(dǎo)致大量失敗。適合庫存熱點比較集中的場景。缺點是會阻塞其他事務(wù)降低吞吐量且對數(shù)據(jù)庫連接占用時間較長。在一些企業(yè)內(nèi)部 ERP、進銷存系統(tǒng)中因為并發(fā)量有限但數(shù)據(jù)一致性要求極高悲觀鎖反而是更簡單的方案。5.4 Redis Lua 預(yù)扣減方案當(dāng)并發(fā)量非常大比如秒殺場景數(shù)據(jù)庫壓力會非常大。這時可以把庫存預(yù)熱到 Redis通過 Lua 腳本原子地完成扣減判斷和扣減操作。Lua 腳本如下-- 文件路徑src/main/resources/lua/stock_deduct.lua local key KEYS[1] local quantity tonumber(ARGV[1]) local stock tonumber(redis.call(get, key)) if stock false then return -1 end if stock - quantity 0 then return 0 end redis.call(decrby, key, quantity) return 1釋放庫存的腳本-- 文件路徑src/main/resources/lua/stock_release.lua local key KEYS[1] local quantity tonumber(ARGV[1]) local stock tonumber(redis.call(get, key)) if stock false then return -1 end redis.call(incrby, key, quantity) return 1Java 調(diào)用示例// 文件路徑src/main/java/com/example/inventory/service/RedisInventoryService.java Service public class RedisInventoryService { Resource private StringRedisTemplate stringRedisTemplate; public static final String STOCK_KEY_PREFIX inventory:stock:; private DefaultRedisScriptLong buildDeductScript() { DefaultRedisScriptLong script new DefaultRedisScript(); script.setLocation(new ClassPathResource(lua/stock_deduct.lua)); script.setResultType(Long.class); return script; } public Long deductStockFromRedis(Long skuId, Integer quantity) { String key STOCK_KEY_PREFIX skuId; return stringRedisTemplate.execute( buildDeductScript(), Collections.singletonList(key), String.valueOf(quantity) ); } }這個方案把“判斷庫存是否充足”和“扣減庫存”放在同一個 Lua 腳本中Redis 會原子執(zhí)行整個腳本不會出現(xiàn)超賣。但要注意Redis 預(yù)扣減成功之后業(yè)務(wù)還沒有真正落庫。如果后續(xù)訂單創(chuàng)建失敗需要調(diào)用釋放腳本回補 Redis 庫存同時還要考慮到數(shù)據(jù)庫庫存最終扣減。這里有一個經(jīng)典的異步雙寫問題先更新 Redis再發(fā) MQ 消息異步扣減數(shù)據(jù)庫庫存如果 MQ 消費失敗則需要定時任務(wù)對賬。推薦的整體鏈路是請求進來先執(zhí)行 Redis Lua 扣減預(yù)庫存?？蹨p成功創(chuàng)建訂單發(fā)送“庫存扣減消息”。MQ 消費者收到消息后在數(shù)據(jù)庫事務(wù)中扣減真實庫存并記錄流水。如果數(shù)據(jù)庫扣減失敗則回補 Redis 庫存并記錄失敗日志。定時任務(wù)比對 Redis 庫存、數(shù)據(jù)庫庫存和流水發(fā)現(xiàn)不一致就告警并人工處理。這種方案結(jié)構(gòu)更復(fù)雜但能支撐較高的并發(fā)。5.5 消息隊列異步扣減通過消息隊列把同一個 SKU 的扣減請求串行化也是一種常見的防超賣方式。例如使用 RabbitMQ 或 RocketMQ訂單服務(wù)在下單時發(fā)送一條扣減消息消息里包含 SKU ID 和數(shù)量。消費端可以保證同一 SKU 的消息串行消費這樣即使服務(wù)層沒有加鎖數(shù)據(jù)庫也不會同時扣減同一個 SKU。這種方式適合削峰但會引入消息中間件增加架構(gòu)復(fù)雜度。訂單狀態(tài)下發(fā)后用戶要等待消息處理完成才能看到庫存結(jié)果。所以一般會和 Redis 預(yù)扣減配合使用而不是完全依賴消息隊列保證不超賣。6. 完整項目代碼示例為了讓整套邏輯更完整這里把核心代碼文件串起來。以下代碼基于 Spring Boot MyBatis Plus重點看庫存更新 SQL 與事務(wù)控制。6.1 pom.xml 依賴!-- 文件路徑pom.xml -- parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies注意不同 Spring Boot 版本對 MyBatis Plus 的兼容性不同。如果使用 Spring Boot 3需要把javax換成jakarta并選擇適配 Spring Boot 3 的 MyBatis Plus 版本。6.2 application.yml 配置# 文件路徑src/main/resources/application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/inventory_demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root redis: host: localhost port: 6379 database: 0 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0如果你的 MySQL 密碼、Redis 密碼與示例不同請改成自己的配置。map-underscore-to-camel-case: true可以讓數(shù)據(jù)庫字段sku_id自動映射到 Java 屬性skuId。6.3 啟動類與實體類// 文件路徑src/main/java/com/example/inventory/InventoryApplication.java SpringBootApplication MapperScan(com.example.inventory.mapper) public class InventoryApplication { public static void main(String[] args) { SpringApplication.run(InventoryApplication.class, args); } }// 文件路徑src/main/java/com/example/inventory/entity/Inventory.java Data TableName(inventory) public class Inventory { TableId(type IdType.AUTO) private Long id; private Long skuId; private Integer totalQuantity; private Integer lockedQuantity; private Integer availableQuantity; private Integer version; }// 文件路徑src/main/java/com/example/inventory/entity/InventoryFlow.java Data TableName(inventory_flow) public class InventoryFlow { TableId(type IdType.AUTO) private Long id; private Long skuId; private String orderId; private Integer changeType; private Integer quantity; private Integer beforeQuantity; private Integer afterQuantity; private String remark; }6.4 Mapper 接口// 文件路徑src/main/java/com/example/inventory/mapper/InventoryMapper.java Mapper public interface InventoryMapper extends BaseMapperInventory { Update(UPDATE inventory SET locked_quantity locked_quantity #{quantity}, available_quantity available_quantity - #{quantity}, version version 1 WHERE sku_id #{skuId} AND available_quantity #{quantity} AND version #{version}) int lockInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity, Param(version) Integer version); Update(UPDATE inventory SET total_quantity total_quantity - #{quantity}, locked_quantity locked_quantity - #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int deductInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity); Update(UPDATE inventory SET locked_quantity locked_quantity - #{quantity}, available_quantity available_quantity #{quantity} WHERE sku_id #{skuId} AND locked_quantity #{quantity}) int releaseInventory(Param(skuId) Long skuId, Param(quantity) Integer quantity); }這里不額外定義InventoryFlowMapper為了節(jié)省篇幅流水寫入在 Service 中通過insert方式完成。你也可以創(chuàng)建一個InventoryFlowMapper繼承BaseMapper。6.5 Service 完整實現(xiàn)// 文件路徑src/main/java/com/example/inventory/service/InventoryService.java Service public class InventoryService { Resource private InventoryMapper inventoryMapper; Transactional(rollbackFor Exception.class) public boolean lockStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.lockInventory(skuId, quantity, inventory.getVersion()); if (rows 0) { throw new RuntimeException(庫存不足或版本沖突請重試); } saveFlow(skuId, orderId, 1, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() - quantity, 下單鎖定庫存); return true; } Transactional(rollbackFor Exception.class) public boolean deductStock(Long skuId, Integer quantity, String orderId) { inventoryMapper.deductInventory(skuId, quantity); Inventory inventory getInventoryBySkuId(skuId); saveFlow(skuId, orderId, 2, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity(), 支付成功扣減庫存); return true; } Transactional(rollbackFor Exception.class) public boolean releaseStock(Long skuId, Integer quantity, String orderId) { Inventory inventory getInventoryBySkuId(skuId); int rows inventoryMapper.releaseInventory(skuId, quantity); if (rows 0) { throw new RuntimeException(釋放庫存失敗); } saveFlow(skuId, orderId, 3, quantity, inventory.getAvailableQuantity(), inventory.getAvailableQuantity() quantity, 訂單取消釋放庫存); return true; } public Inventory getInventoryBySkuId(Long skuId) { Inventory inventory inventoryMapper.selectOne( new LambdaQueryWrapperInventory() .eq(Inventory::getSkuId, skuId) ); if (inventory null) { throw new RuntimeException(SKU不存在); } return inventory; } private void saveFlow(Long skuId, String orderId, Integer changeType, Integer quantity, Integer beforeQuantity, Integer afterQuantity, String remark) { InventoryFlow flow new InventoryFlow(); flow.setSkuId(skuId); flow.setOrderId(orderId); flow.setChangeType(changeType); flow.setQuantity(quantity); flow.setBeforeQuantity(beforeQuantity); flow.setAfterQuantity(afterQuantity); flow.setRemark(remark); inventoryFlowMapper.insert(flow); } }如果你的項目沒有注入InventoryFlowMapper記得在 Service 中補充定義Resource private InventoryFlowMapper inventoryFlowMapper;并且創(chuàng)建對應(yīng)的 Mapper// 文件路徑src/main/java/com/example/inventory/mapper/InventoryFlowMapper.java Mapper public interface InventoryFlowMapper extends BaseMapperInventoryFlow { }6.6 Controller 示例// 文件路徑src/main/java/com/example/inventory/controller/InventoryController.java RestController RequestMapping(/inventory) public class InventoryController { Resource private InventoryService inventoryService; GetMapping(/get) public Inventory getInventory(Long skuId) { return inventoryService.getInventoryBySkuId(skuId); } PostMapping(/lock) public String lock(RequestBody LockRequest request) { inventoryService.lockStock(request.getSkuId(), request.getQuantity(), request.getOrderId()); return success; } PostMapping(/deduct) public String deduct(RequestBody LockRequest request) { inventoryService.deductStock(request.getSkuId(), request.getQuantity(), request.getOrderId()); return success; } PostMapping(/release) public String release(RequestBody LockRequest request) { inventoryService.releaseStock(request.getSkuId(), request.getQuantity(), request.getOrderId()); return success; } Data public static class LockRequest { private Long skuId; private Integer quantity; private String orderId; } }到這里一套基于數(shù)據(jù)庫事務(wù)條件的庫存閉合鏈路已經(jīng)跑通。你可以把項目啟動后按照 4.5 中的請求示例測試。7. 常見問題與排查思路在實際開發(fā)中庫存模塊的高頻問題往往不是代碼寫不出來而是并發(fā)或者數(shù)據(jù)一致性出問題。下面整理了一份排查清單。問題現(xiàn)象常見原因解決思路庫存扣成負數(shù)先查庫存再更新沒有原子條件使用條件更新available_quantity quantity樂觀鎖沖突導(dǎo)致下單失敗并發(fā)高版本號頻繁不匹配增加重試機制或切換悲觀鎖/Redis Lua鎖定庫存后訂單未支付庫存不釋放沒有超時釋放機制增加訂單超時自動取消任務(wù)并調(diào)用釋放庫存接口Redis 預(yù)扣減成功但數(shù)據(jù)庫庫存最終沒扣MQ 消費失敗或漏發(fā)消息增加定時對賬用流水表比對待扣減記錄庫存流水與庫存表不一致更新庫存和寫入流水不在同一事務(wù)確保庫存更新、流水插入在同一個Transactional內(nèi)重復(fù)扣減庫存接口沒有做冪等控制使用訂單號或業(yè)務(wù)單號做唯一索引重復(fù)請求直接拒絕查詢庫存很慢缺少索引或全表掃描為sku_id建唯一索引流水表建order_id/sku_id索引同一 SKU 并發(fā)下單時吞吐量低使用行鎖或悲觀鎖阻塞使用 Redis 預(yù)扣減 MQ 異步落庫如果遇到庫存異常建議排查順序如下查庫存流水找對應(yīng)order_id下的變更記錄。對比流水中before_quantity和after_quantity確認變化量是否連續(xù)。查 Redis 當(dāng)前庫存和數(shù)據(jù)庫庫存看兩者是否一致。查服務(wù)日志重點看數(shù)據(jù)庫更新影響行數(shù)是否為 0。如果發(fā)現(xiàn)流水缺失檢查事務(wù)是否回滾或者是否繞過了庫存服務(wù)直接更新數(shù)據(jù)庫。8. 最佳實踐與工程建議做完一個基礎(chǔ)庫存模塊后想在項目里真正穩(wěn)定運行還需要注意下面這些工程問題。第一所有庫存變更必須走同一個庫存服務(wù)。很多系統(tǒng)出現(xiàn)庫存不一致是因為不同模塊各寫各的UPDATE inventory語句。有的在訂單服務(wù)扣有的在售后服務(wù)扣有的直接在 DB 管理工具里手工改。建議所有庫存操作都收斂到獨立的 inventory 服務(wù)或獨立 Service 中方便統(tǒng)一加鎖、統(tǒng)一寫流水、統(tǒng)一監(jiān)控。第二庫存流水要設(shè)置唯一約束和冪等鍵。比如用order_id change_type sku_id作為業(yè)務(wù)冪等鍵防止消息重復(fù)消費、接口重試導(dǎo)致重復(fù)扣減?？梢越oinventory_flow增加唯一索引ALTER TABLE inventory_flow ADD UNIQUE KEY uk_order_change_sku (order_id, change_type, sku_id);第三庫存表更新時盡量使用行級條件更新避免“查出來再判斷”的寫法。哪怕只是簡單扣減也要習(xí)慣把庫存充足條件寫到 SQL 的WHERE中。第四引入 Redis 后要考慮緩存與數(shù)據(jù)庫的一致性問題。建議采用以下策略啟動或運營編輯庫存后主動刷新 Redis 庫存。Redis 庫存設(shè)置合理過期時間比如 30 分鐘過期后回源數(shù)據(jù)庫。每次數(shù)據(jù)庫庫存扣減成功后刪除 Redis 緩存讓下一次讀取重新加載。定時任務(wù)每 5 分鐘掃描 Redis 庫存和數(shù)據(jù)庫庫存差異異常時告警。第五庫存扣減失敗一定要有明確的錯誤碼。不要說“系統(tǒng)繁忙”至少區(qū)分庫存不足商品不存在重復(fù)操作庫存服務(wù)超時這樣前端和客戶端才能做差異化提示。第六生產(chǎn)環(huán)境中的庫存調(diào)整必須走審批和審計。運營手工調(diào)整庫存是風(fēng)險很高的操作建議提供獨立的管理端接口操作記錄寫入操作日志并且不能直接連數(shù)據(jù)庫修改業(yè)務(wù)表。第七事務(wù)超時和數(shù)據(jù)庫連接需要注意。悲觀鎖方案中如果事務(wù)內(nèi)有遠程調(diào)用很容易出現(xiàn)長事務(wù)。建議庫存事務(wù)內(nèi)只做數(shù)據(jù)庫操作不要嵌套外部 HTTP 請求。遠程調(diào)用放在事務(wù)提交后再執(zhí)行。9. 總結(jié)與學(xué)習(xí)路線本文圍繞庫存管理完整梳理了從數(shù)據(jù)模型、表設(shè)計到庫存鎖定、扣減、釋放的落地流程也分析了樂觀鎖、悲觀鎖、Redis Lua 預(yù)扣減和 MQ 異步消峰幾種主流并發(fā)方案。你可以根據(jù)項目規(guī)模選擇合適的方案中小系統(tǒng)先用數(shù)據(jù)庫條件更新即可高并發(fā)場景再逐步引入 Redis 和消息隊列。接下來可以繼續(xù)學(xué)習(xí)這些方向訂單超時自動取消結(jié)合延遲消息或定時任務(wù)釋放庫存。庫存對賬系統(tǒng)通過流水表每日核對訂單與庫存數(shù)據(jù)。分布式事務(wù)跨服務(wù)和跨庫時如何保證庫存與訂單一致。多倉庫庫存在庫存模型中增加倉庫維度做倉配庫存管理。庫存盤點結(jié)合 Redis 和數(shù)據(jù)庫實現(xiàn)高并發(fā)盤點邏輯。在實際項目中不建議一上來就堆 Redis、MQ、分布式事務(wù)。先把單庫事務(wù)版本的庫存鏈路跑通再把 Redis 預(yù)扣減引入熱點商品最后根據(jù)業(yè)務(wù)體量決定是否引入異步隊列。這種循序漸進的方式更容易排查問題也更容易保證系統(tǒng)穩(wěn)定。如果這篇文章對你有幫助可以收藏備用。下次遇到庫存超賣、鎖庫存失敗或者流水對不上時按照本文的思路一步步排查大多數(shù)問題都能快速定位。