簡(jiǎn)介這份《庫(kù)存管理系統(tǒng)設(shè)計(jì)方案》是一份面向管理信息系統(tǒng)初學(xué)者、相關(guān)專業(yè)學(xué)生及企業(yè)信息化人員的完整設(shè)計(jì)方案文檔。內(nèi)容圍繞庫(kù)存管理系統(tǒng)的建設(shè)展開(kāi)從MIS基本概念、研究背景與意義入手系統(tǒng)梳理了數(shù)據(jù)庫(kù)系統(tǒng)設(shè)計(jì)與SQL語(yǔ)言應(yīng)用并以Visual Basic搭配Access 2000為開(kāi)發(fā)工具詳細(xì)說(shuō)明了需求分析、模塊劃分、數(shù)據(jù)庫(kù)設(shè)計(jì)與程序結(jié)構(gòu)等環(huán)節(jié)。通過(guò)入庫(kù)、出庫(kù)、庫(kù)存查詢、庫(kù)存預(yù)警等功能模塊展示了如何實(shí)現(xiàn)數(shù)據(jù)一致性強(qiáng)、安全性較高的庫(kù)存管理應(yīng)用系統(tǒng)。資源為1個(gè)doc文檔壓縮包大小約604KB篇幅完整、結(jié)構(gòu)清晰其中包含需求分析、模塊劃分、數(shù)據(jù)庫(kù)設(shè)計(jì)、程序結(jié)構(gòu)及源代碼等章節(jié)適合用于課程設(shè)計(jì)參考、畢業(yè)設(shè)計(jì)選題或企業(yè)庫(kù)存管理系統(tǒng)的早期方案借鑒。已有126人學(xué)習(xí)下載具備一定的參考價(jià)值。1. 庫(kù)存管理系統(tǒng)設(shè)計(jì)方案賬面庫(kù)存不等于可用庫(kù)存的落差某電商團(tuán)隊(duì)的新系統(tǒng)上線第三周前臺(tái)仍然顯示“有貨”倉(cāng)庫(kù)里卻已經(jīng)空了。后臺(tái)工程師核對(duì)數(shù)據(jù)后發(fā)現(xiàn)系統(tǒng)里的“庫(kù)存”做得就像一個(gè)計(jì)數(shù)器入庫(kù)加、出庫(kù)減減到負(fù)數(shù)也不管盤(pán)點(diǎn)差異全靠人肉改數(shù)。這個(gè)場(chǎng)景不是在講某個(gè)開(kāi)源項(xiàng)目而是在講「庫(kù)存管理系統(tǒng)設(shè)計(jì)方案」這個(gè)文檔到底該覆蓋什么。一套能用的方案核心不是把增刪改查寫(xiě)完而是要定義清楚四件事庫(kù)存賬長(zhǎng)什么樣、每筆變動(dòng)從哪來(lái)、并發(fā)下怎么保證不超賣、盤(pán)點(diǎn)對(duì)不上賬時(shí)怎么處置。這篇筆記就按這個(gè)順序展開(kāi)適合準(zhǔn)備從零搭建庫(kù)存系統(tǒng)或正在重構(gòu)老庫(kù)存模塊的工程師。方案里不引入微服務(wù)、不堆中間件全部基于一個(gè)關(guān)系型數(shù)據(jù)庫(kù)就能落地。2. 先把架子搭對(duì)模塊邊界、數(shù)據(jù)流向與單據(jù)先行2.1 六個(gè)核心模塊劃分庫(kù)存臺(tái)賬是唯一事實(shí)源我把一個(gè)標(biāo)準(zhǔn)庫(kù)存管理系統(tǒng)拆成六個(gè)模塊商品中心、倉(cāng)庫(kù)中心、單據(jù)中心、庫(kù)存臺(tái)賬、庫(kù)存流水、對(duì)賬與預(yù)警。商品中心管 SKU 與計(jì)量單位倉(cāng)庫(kù)中心管倉(cāng)庫(kù)、庫(kù)位、庫(kù)區(qū)狀態(tài)單據(jù)中心管所有庫(kù)存變動(dòng)的來(lái)源包括采購(gòu)入庫(kù)單、銷售出庫(kù)單、盤(pán)點(diǎn)單、調(diào)撥單、調(diào)整單臺(tái)賬管實(shí)時(shí)余量流水管每一筆變動(dòng)軌跡對(duì)賬與預(yù)警做每日勾稽和異常提醒。這個(gè)劃分里最關(guān)鍵的一條紅線是庫(kù)存臺(tái)賬是全系統(tǒng)唯一的“事實(shí)源”任何時(shí)候要回答“現(xiàn)在有多少貨”只看臺(tái)賬表不看單據(jù)匯總不算歷史加減。很多系統(tǒng)翻車就是因?yàn)椴煌K各算各的賬采購(gòu)模塊問(wèn)采購(gòu)數(shù)、銷售模塊問(wèn)可賣數(shù)兩邊數(shù)據(jù)不一致最后線上超賣、倉(cāng)庫(kù)空轉(zhuǎn)。臺(tái)賬獨(dú)立出來(lái)的好處是所有模塊共用同一份數(shù)據(jù)任何模塊要改庫(kù)存必須先寫(xiě)單據(jù)再由單據(jù)去驅(qū)動(dòng)臺(tái)賬變化。我一般還會(huì)在倉(cāng)庫(kù)中心里給庫(kù)位加一個(gè)狀態(tài)字段標(biāo)記“正?！薄皟鼋Y(jié)”“盤(pán)點(diǎn)中”。這個(gè)字段看著不起眼但在后面處理盤(pán)點(diǎn)凍結(jié)和庫(kù)位隔離時(shí)會(huì)省掉大量麻煩。如果你要接倉(cāng)儲(chǔ)作業(yè)WMS這個(gè)模塊可以直接擴(kuò)展成庫(kù)位級(jí)的上架、揀貨、復(fù)核不需要改臺(tái)賬結(jié)構(gòu)。2.2 數(shù)據(jù)流向與單據(jù)驅(qū)動(dòng)先有單據(jù)、后有庫(kù)存變動(dòng)單據(jù)驅(qū)動(dòng)是這套方案的第二個(gè)紅線。簡(jiǎn)單說(shuō)不允許任何代碼路徑直接對(duì) inventory_balance 做 UPDATE 或 INSERT所有庫(kù)存變動(dòng)必須經(jīng)過(guò)“單據(jù)審核 → 臺(tái)賬變動(dòng) → 流水記錄 → 單據(jù)完成”這條鏈路。我設(shè)計(jì)單據(jù)狀態(tài)時(shí)只保留四個(gè)狀態(tài)草稿、已審核、已完成、已作廢。草稿是錄入階段不影響庫(kù)存已審核代表單據(jù)業(yè)務(wù)上已生效但還沒(méi)扣減庫(kù)存已完成代表庫(kù)存事務(wù)已經(jīng)成功提交已作廢用于反操作。日常最容易踩的坑是客服說(shuō)訂單取消開(kāi)發(fā)為了省事直接寫(xiě)一條 UPDATE 把庫(kù)存加回去。這個(gè)操作當(dāng)時(shí)沒(méi)問(wèn)題但月底對(duì)賬時(shí)流水里找不到這筆回補(bǔ)賬就永遠(yuǎn)對(duì)不平了。正確的反操作流程是原銷售出庫(kù)單作廢生成一張紅字沖銷單沖銷單審核后走一次庫(kù)存增加流水里留下“SALES_RETURN / 銷售退貨”類型的記錄。這樣一來(lái)臺(tái)賬、流水、單據(jù)三者始終能對(duì)上對(duì)賬腳本只需要檢查“臺(tái)賬期末 臺(tái)賬期初 流水發(fā)生額”就夠了不用猜測(cè)某一筆數(shù)據(jù)是人肉改的。2.3 技術(shù)選型參考從單庫(kù)到可擴(kuò)展的折中方案技術(shù)選型不用追求新潮庫(kù)存系統(tǒng)對(duì)一致性要求遠(yuǎn)高于對(duì)性能的要求。第一版建議用一個(gè)支持事務(wù)的關(guān)系型數(shù)據(jù)庫(kù)比如 MySQL 或 PostgreSQL單實(shí)例部署臺(tái)賬和流水放同一個(gè)庫(kù)。緩存只用來(lái)做熱點(diǎn) SKU 的查詢加速不參與扣減扣減永遠(yuǎn)回源到數(shù)據(jù)庫(kù)。我整理了這樣一張選型參考表層選型理由數(shù)據(jù)庫(kù)MySQL/PostgreSQL事務(wù)保證行鎖與樂(lè)觀鎖成熟緩存Redis只緩存查詢結(jié)果不作為扣減依據(jù)應(yīng)用層任選后端語(yǔ)言事務(wù)邊界由代碼控制語(yǔ)言無(wú)關(guān)分庫(kù)分表暫不做單庫(kù)可以支撐絕大多數(shù)中小業(yè)務(wù)量為什么我不建議第一版就上分庫(kù)分表因?yàn)閹?kù)存表按 SKU 維度存儲(chǔ)熱點(diǎn)行其實(shí)很集中分庫(kù)后跨庫(kù)事務(wù)會(huì)讓“扣減流水單據(jù)完成”的一致性變得非常難做。真到單庫(kù)扛不住的時(shí)候優(yōu)先把流水表按月分區(qū)或歸檔臺(tái)賬表依然單庫(kù)單表這樣能撐更久。記住一個(gè)原則庫(kù)存方案先求對(duì)再求快性能問(wèn)題可以用緩存擋一致性問(wèn)題擋不住。3. 庫(kù)存核心表設(shè)計(jì)表建對(duì)了一半的坑就消失了3.1 庫(kù)存余額表把維度和數(shù)量約束立住庫(kù)存余額表的粒度是“倉(cāng)庫(kù) 庫(kù)位 SKU”這張表只存當(dāng)前實(shí)時(shí)數(shù)量不存歷史。字段上我會(huì)拆出三個(gè)數(shù)量字段quantity 表示賬面總庫(kù)存locked_quantity 表示已被訂單預(yù)占的數(shù)量?jī)烧呦鄿p就是可賣庫(kù)存。不把可賣庫(kù)存單獨(dú)冗余成一個(gè)字段是為了避免出現(xiàn)“總量對(duì)、可賣不對(duì)”的臟數(shù)據(jù)。我一般這樣建表CREATE TABLE inventory_balance ( id BIGINT PRIMARY KEY AUTO_INCREMENT, warehouse_id BIGINT NOT NULL COMMENT 倉(cāng)庫(kù)ID, location_id BIGINT NOT NULL COMMENT 庫(kù)位ID, sku_id BIGINT NOT NULL COMMENT 商品SKU ID, quantity INT NOT NULL DEFAULT 0 COMMENT 賬面庫(kù)存總量, locked_quantity INT NOT NULL DEFAULT 0 COMMENT 預(yù)占鎖定數(shù)量, version INT NOT NULL DEFAULT 0 COMMENT 樂(lè)觀鎖版本號(hào), created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_wh_loc_sku (warehouse_id, location_id, sku_id), CONSTRAINT chk_quantity CHECK (quantity 0), CONSTRAINT chk_locked CHECK (locked_quantity 0 AND locked_quantity quantity) ) COMMENT 庫(kù)存余額表;注意兩個(gè)約束quantity 必須大于等于 0locked_quantity 必須小于等于 quantity。這兩個(gè)約束是防超賣的最后一道閘門(mén)。但要特別提醒MySQL 5.7 及以下對(duì) CHECK 約束是解析通過(guò)但不強(qiáng)制執(zhí)行的實(shí)際生效得靠應(yīng)用層事務(wù)里的條件更新。如果你用的版本不支持 CHECK一定要在扣減 SQL 的 WHERE 條件里帶上數(shù)量判斷而不能只依賴代碼里的 if。唯一索引 uk_wh_loc_sku 保證同一倉(cāng)庫(kù)同一庫(kù)位同一 SKU 只有一行。這樣做的直接好處是扣減時(shí)可以用行鎖鎖定這一行不會(huì)因?yàn)椴l(fā)插入產(chǎn)生多條記錄。如果你把庫(kù)位維度去掉直接按“倉(cāng)庫(kù) SKU”建表會(huì)讓很多庫(kù)位管理、盤(pán)點(diǎn)凍結(jié)的功能做不深入。建議一開(kāi)始就帶上庫(kù)位哪怕當(dāng)前用不到。3.2 庫(kù)存流水表每一筆變動(dòng)都要能回放流水表是庫(kù)存系統(tǒng)的黑匣子它的價(jià)值在出問(wèn)題時(shí)才體現(xiàn)出來(lái)。我設(shè)計(jì)的流水表不只記錄“增加了多少、減少了多少”還把變動(dòng)前數(shù)量、變動(dòng)后數(shù)量、來(lái)源單據(jù)號(hào)、變動(dòng)類型都存下來(lái)。這樣任何一筆可疑變動(dòng)都可以直接回放出來(lái)不需要翻業(yè)務(wù)日志。CREATE TABLE inventory_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flow_no VARCHAR(32) NOT NULL COMMENT 流水號(hào), doc_type VARCHAR(32) NOT NULL COMMENT 單據(jù)類型PO/SO/RETURN/ALLOCATE/CHECK/ADJUST, doc_no VARCHAR(32) NOT NULL COMMENT 來(lái)源單據(jù)號(hào), change_type VARCHAR(32) NOT NULL COMMENT 變動(dòng)類型IN/OUT/LOCK/UNLOCK/CHECK_IN/CHECK_OUT, sku_id BIGINT NOT NULL COMMENT 商品SKU ID, warehouse_id BIGINT NOT NULL COMMENT 倉(cāng)庫(kù)ID, location_id BIGINT NOT NULL COMMENT 庫(kù)位ID, before_qty INT NOT NULL COMMENT 變動(dòng)前賬面總量, change_qty INT NOT NULL COMMENT 變動(dòng)量正數(shù)增加負(fù)數(shù)減少, after_qty INT NOT NULL COMMENT 變動(dòng)后賬面總量, operator VARCHAR(32) NOT NULL COMMENT 操作人, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_doc (doc_type, doc_no), KEY idx_sku_time (sku_id, created_at) ) COMMENT 庫(kù)存流水表;關(guān)鍵點(diǎn)是 before_qty 和 after_qty 不能省。只存 change_qty 的話某天數(shù)據(jù)出問(wèn)題想確認(rèn)“當(dāng)時(shí)是不是真的從 50 變成了 10”還得靠猜。有了前后值對(duì)賬時(shí)可以精確檢查每一步加減是否符合預(yù)期。流水表不需要唯一鍵約束流水號(hào)但生產(chǎn)環(huán)境我會(huì)給 flow_no 加一個(gè)唯一索引防止重復(fù)寫(xiě)入。流水表會(huì)漲得很快建議定期歸檔。做法是按 created_at 做月度分區(qū)三個(gè)月前的分區(qū)數(shù)據(jù)遷到歷史庫(kù)。日常查詢盡量都帶 sku_id 和 created_at 范圍避免全表掃描拖垮主庫(kù)。記住流水表永遠(yuǎn)只追加不 UPDATE、不 DELETE這是審計(jì)的基本前提。3.3 鎖與并發(fā)樂(lè)觀鎖選型與悲觀鎖的邊界庫(kù)存系統(tǒng)并發(fā)扣減是逃不開(kāi)的問(wèn)題。我的默認(rèn)方案是樂(lè)觀鎖加版本號(hào)寫(xiě) SQL 時(shí)把版本號(hào)作為 WHERE 條件一條 UPDATE 同時(shí)完成“判斷數(shù)量、扣減、版本號(hào)自增”。這樣做的好處是不用顯式開(kāi)啟事務(wù)去鎖行性能好。UPDATE inventory_balance SET quantity quantity - 1, version version 1 WHERE id 123 AND quantity 1 AND version 5;這條 SQL 影響行數(shù)為 1 說(shuō)明扣減成功為 0 說(shuō)明版本沖突或庫(kù)存不足應(yīng)用層捕獲后重新查詢?cè)僦卦?。參?shù)上要注意兩點(diǎn)第一個(gè)是 version 必須用舊值去匹配不能寫(xiě)成 version 5否則重試就沒(méi)有意義第二個(gè)是 quantity 1 這個(gè)條件不能省它是并發(fā)下防超賣的關(guān)鍵。樂(lè)觀鎖的缺點(diǎn)是當(dāng)同一個(gè)熱門(mén) SKU 并發(fā)非常高時(shí)大部分請(qǐng)求都會(huì)因?yàn)榘姹緵_突失敗重試反而放大數(shù)據(jù)庫(kù)壓力。我一般以單 SKU 每秒幾十筆以上的扣減量為分界線超過(guò)這個(gè)量就換成悲觀鎖用 SELECT ... FOR UPDATE 鎖住那一行讓請(qǐng)求排隊(duì)處理。對(duì)大多數(shù)業(yè)務(wù)來(lái)說(shuō)樂(lè)觀鎖完全夠用沒(méi)必要一上來(lái)就上悲觀鎖。還有一個(gè)折中做法把熱門(mén) SKU 的庫(kù)存拆分到多個(gè)庫(kù)存行比如 1000 件拆成 10 行每行 100 件扣減時(shí)隨機(jī)選行從設(shè)計(jì)上降低沖突概率。這個(gè)方案帶來(lái)一個(gè)新問(wèn)題——盤(pán)點(diǎn)時(shí)要把多行合并所以我只在活動(dòng)大促場(chǎng)景臨時(shí)用日常不拆。4. 入庫(kù)、出庫(kù)與盤(pán)點(diǎn)三大流程的狀態(tài)機(jī)落地4.1 入庫(kù)流程采購(gòu)入庫(kù)與退貨入庫(kù)的兩種沖銷邏輯入庫(kù)不只是“加庫(kù)存”。采購(gòu)入庫(kù)增加的是可賣庫(kù)存而銷售退貨入庫(kù)要區(qū)分“還能不能賣”能賣的進(jìn)正常庫(kù)存不能賣的進(jìn)次品庫(kù)位。我用一張庫(kù)存調(diào)整單來(lái)承載這些差異而不是直接改臺(tái)賬。采購(gòu)入庫(kù)的流程是采購(gòu)單審核后生成入庫(kù)單倉(cāng)庫(kù)掃碼確認(rèn)后在一個(gè)事務(wù)里更新臺(tái)賬、寫(xiě)流水、置單據(jù)完成。def confirm_purchase_in(doc_no, items): with db.transaction(): doc get_doc(doc_no) if doc.status ! APPROVED: raise BizException(單據(jù)未審核不能入庫(kù)) for item in items: # 更新臺(tái)賬不存在則插入新行存在則累加 updated db.execute( UPDATE inventory_balance SET quantity quantity %s, version version 1 WHERE warehouse_id %s AND location_id %s AND sku_id %s, (item.qty, item.warehouse_id, item.location_id, item.sku_id) ) if updated 0: insert_balance(item) # 寫(xiě)流水 insert_flow(doc_typePO, doc_nodoc_no, change_typeIN, change_qtyitem.qty) # 最后才把單據(jù)置為完成 update_doc_status(doc_no, DONE)這里的事務(wù)邊界要特別注意先判斷單據(jù)狀態(tài)、再更新臺(tái)賬、再寫(xiě)流水、最后更新單據(jù)狀態(tài)四步必須在同一個(gè)事務(wù)里。如果在更新完臺(tái)賬之后事務(wù)還沒(méi)提交服務(wù)就重啟了回滾會(huì)把臺(tái)賬和數(shù)據(jù)恢復(fù)到一致?tīng)顟B(tài)不會(huì)出現(xiàn)“流水有了、臺(tái)賬沒(méi)變”的中間臟數(shù)據(jù)。insert_balance 的時(shí)候要注意唯一鍵沖突并發(fā)下第一筆插入和第二筆更新可能同時(shí)發(fā)生穩(wěn)妥做法是捕獲唯一鍵沖突后轉(zhuǎn)成 UPDATE或者直接使用 INSERT ... ON DUPLICATE KEY UPDATE。4.2 出庫(kù)流程預(yù)占、扣減、回滾出庫(kù)是庫(kù)存系統(tǒng)里最考驗(yàn)設(shè)計(jì)的一環(huán)。我堅(jiān)持“預(yù)占與扣減分離”下單成功后鎖定庫(kù)存訂單發(fā)貨后才真正扣減。預(yù)占階段把可賣數(shù)量轉(zhuǎn)成鎖定數(shù)量可賣數(shù)量減少但總庫(kù)存不變扣減階段把總庫(kù)存和鎖定數(shù)量一起減少。這樣既防止超賣又允許訂單取消時(shí)釋放預(yù)占。-- 預(yù)占可賣數(shù)量 quantity - locked_quantity必須足夠 UPDATE inventory_balance SET locked_quantity locked_quantity %s, version version 1 WHERE warehouse_id %s AND location_id %s AND sku_id %s AND quantity - locked_quantity %s;這條 SQL 是防超賣的核心影響行數(shù)為 1 代表預(yù)占成功為 0 代表庫(kù)存不足。參數(shù)里那個(gè) quantity - locked_quantity %s 是原子判斷必須在一條 SQL 里完成不能先查出來(lái)再在應(yīng)用層判斷否則高并發(fā)下兩個(gè)請(qǐng)求同時(shí)查到“還剩 10 件”各自扣 8 件最后就超賣了。預(yù)占成功后寫(xiě)一條 LOCK 類型的流水訂單號(hào)記錄在 doc_no 里方便后續(xù)釋放。扣減階段則在一個(gè)事務(wù)里完成總庫(kù)存減少、鎖定數(shù)量減少、寫(xiě) OUT 流水、更新發(fā)貨單狀態(tài)。如果訂單走到發(fā)貨前被取消要新建一張作廢單把 locked_quantity 減回去寫(xiě)一條 UNLOCK 流水。這里最容易做錯(cuò)的是取消訂單時(shí)只減 locked_quantity 不減 quantity導(dǎo)致總庫(kù)存虛高。記住鎖定時(shí)不動(dòng) quantity扣減時(shí)同時(shí)動(dòng) quantity 和 locked_quantity釋放時(shí)只動(dòng) locked_quantity三者各有語(yǔ)義混了賬就亂了。4.3 盤(pán)點(diǎn)流程凍結(jié)、實(shí)盤(pán)、差異調(diào)整盤(pán)點(diǎn)不能“邊賣邊數(shù)”否則數(shù)出來(lái)的結(jié)果毫無(wú)意義。我的做法是三步走盤(pán)點(diǎn)前凍結(jié)庫(kù)位或 SKU 范圍盤(pán)點(diǎn)時(shí)錄入實(shí)盤(pán)數(shù)量盤(pán)點(diǎn)完成后生成盤(pán)盈盤(pán)虧調(diào)整單。凍結(jié)的本質(zhì)是限制業(yè)務(wù)單據(jù)對(duì)凍結(jié)范圍內(nèi)庫(kù)存的操作出庫(kù)單和調(diào)撥單在凍結(jié)期間不允許審核通過(guò)。-- 盤(pán)點(diǎn)差異計(jì)算賬面數(shù) vs 實(shí)盤(pán)數(shù) SELECT b.quantity AS book_qty, c.count_qty AS counted_qty, c.count_qty - b.quantity AS diff_qty FROM inventory_balance b JOIN check_snapshot c ON b.sku_id c.sku_id AND b.location_id c.location_id WHERE c.check_id %s AND c.count_qty ! b.quantity;盤(pán)點(diǎn)結(jié)果不會(huì)直接改動(dòng) inventory_balance而是生成盤(pán)盈盤(pán)虧調(diào)整單。盤(pán)盈走 IN 類型的調(diào)整盤(pán)虧走 OUT 類型的調(diào)整兩張單據(jù)都必須寫(xiě)明原因比如“倉(cāng)庫(kù)盤(pán)點(diǎn)差異”“損耗”。這樣臺(tái)賬變動(dòng)永遠(yuǎn)有單據(jù)支撐盤(pán)點(diǎn)對(duì)賬才能閉環(huán)。我在 check_snapshot 表里會(huì)保存盤(pán)點(diǎn)時(shí)點(diǎn)的賬面快照而不是直接關(guān)聯(lián)當(dāng)前余量表防止盤(pán)點(diǎn)期間余量變化導(dǎo)致差異算不準(zhǔn)。提示盤(pán)點(diǎn)期間如果業(yè)務(wù)不允許凍結(jié)太長(zhǎng)時(shí)間至少要在生成盤(pán)點(diǎn)單時(shí)記錄賬面快照并在盤(pán)點(diǎn)確認(rèn)前校驗(yàn)該范圍是否發(fā)生過(guò)出入庫(kù)流水發(fā)生過(guò)的一律強(qiáng)制重盤(pán)不要直接按實(shí)盤(pán)數(shù)覆蓋。5. 庫(kù)存翻車現(xiàn)場(chǎng)盤(pán)點(diǎn)和并發(fā)下的五個(gè)典型坑及排查路徑5.1 負(fù)庫(kù)存數(shù)據(jù)庫(kù) check 約束沒(méi)攔住現(xiàn)象某 SKU 賬面數(shù)量變成 -3訂單依然在正常發(fā)出財(cái)務(wù)對(duì)賬發(fā)現(xiàn)庫(kù)存金額是負(fù)數(shù)。原因數(shù)據(jù)庫(kù)版本不強(qiáng)制校驗(yàn) CHECK 約束應(yīng)用層判斷庫(kù)存足夠的邏輯在并發(fā)下同時(shí)通過(guò)兩條扣減同時(shí)執(zhí)行就把數(shù)量扣成了負(fù)數(shù)。解決把數(shù)量判斷下沉到 UPDATE 語(yǔ)句的 WHERE 條件里用一條 SQL 原子完成“查庫(kù)存、扣數(shù)量”。同時(shí)加一個(gè)定時(shí)任務(wù)每天掃描 inventory_balance 里 quantity 小于 0 的記錄第一時(shí)間報(bào)警。不要指望開(kāi)發(fā)人員在所有代碼路徑上都記得加判斷數(shù)據(jù)庫(kù)和 SQL 層的約束才是最后一道閘門(mén)。5.2 盤(pán)點(diǎn)期間照常出庫(kù)賬面庫(kù)存被覆蓋現(xiàn)象倉(cāng)庫(kù)盤(pán)點(diǎn)一個(gè)庫(kù)位花了三個(gè)小時(shí)盤(pán)點(diǎn)確認(rèn)后差異異常大重盤(pán)兩次數(shù)據(jù)還是對(duì)不上。原因盤(pán)點(diǎn)單生成后業(yè)務(wù)仍然在這個(gè)庫(kù)位正常出庫(kù)到確認(rèn)盤(pán)點(diǎn)結(jié)果時(shí)系統(tǒng)直接把臺(tái)賬數(shù)量改成實(shí)盤(pán)數(shù)期間出庫(kù)的數(shù)量被覆蓋了。賬面、流水、實(shí)盤(pán)三者已經(jīng)不一致之后怎么對(duì)都對(duì)不平。解決盤(pán)點(diǎn)單審核時(shí)嚴(yán)格凍結(jié)庫(kù)位凍結(jié)范圍內(nèi)不允許出庫(kù)和調(diào)撥如果凍結(jié)會(huì)影響業(yè)務(wù)那就退而求其次在盤(pán)點(diǎn)確認(rèn)前檢查凍結(jié)時(shí)間內(nèi)該范圍有沒(méi)有新增流水有流水的 SKU 自動(dòng)剔除強(qiáng)制重新盤(pán)點(diǎn)。這一步必須做成系統(tǒng)邏輯不能靠倉(cāng)庫(kù)主管口頭協(xié)調(diào)。5.3 樂(lè)觀鎖版本號(hào)更新放錯(cuò)位置重試邏輯白寫(xiě)現(xiàn)象加了 version 字段后并發(fā)扣減偶爾會(huì)丟更新重試機(jī)制一直沒(méi)有生效。原因應(yīng)用層把版本號(hào)比較和更新拆成了兩步第一步查出 version5第二步執(zhí)行UPDATE ... SET quantityquantity-1 WHERE id123完全沒(méi)帶版本號(hào)條件或者帶了條件但 SET 里沒(méi)有 versionversion1。這等于樂(lè)觀鎖形同虛設(shè)。解決版本號(hào)更新必須和業(yè)務(wù)字段更新放在同一條 SQL 里即UPDATE ... SET quantity quantity - %s, version version 1 WHERE id %s AND version %s。重試邏輯要捕獲“影響行數(shù)為 0”的結(jié)果重新查詢最新版本號(hào)后再次執(zhí)行。還有一個(gè)容易忽略的細(xì)節(jié)重試之后業(yè)務(wù)邏輯要整體重新計(jì)算不能只換版本號(hào)、庫(kù)存數(shù)量還按舊值算。5.4 調(diào)撥或移庫(kù)時(shí)兩步更新不在一個(gè)事務(wù)現(xiàn)象調(diào)撥單顯示已完成但兩個(gè)倉(cāng)庫(kù)的庫(kù)存都變少了或者一個(gè)多了另一個(gè)沒(méi)少月底一查全是這種半截賬。原因跨倉(cāng)調(diào)撥被實(shí)現(xiàn)成“出庫(kù)倉(cāng)減庫(kù)存、入庫(kù)倉(cāng)加庫(kù)存”兩條獨(dú)立 UPDATE第一條成功了、第二條失敗事務(wù)沒(méi)有回滾。解決調(diào)撥單必須在一個(gè)數(shù)據(jù)庫(kù)事務(wù)里完成先減后加任一步失敗整體回滾。如果未來(lái)要跨庫(kù)調(diào)撥需要引入分布式事務(wù)或本地消息表但在單庫(kù)階段直接一個(gè)事務(wù)包住兩步更新就是最可靠的做法。排查時(shí)優(yōu)先看 inventory_flow 里 ALLOCATE 相關(guān)的流水兩邊單據(jù)號(hào)應(yīng)該成對(duì)出現(xiàn)。5.5 直接更新臺(tái)賬修數(shù)據(jù)流水成了擺設(shè)現(xiàn)象某天發(fā)現(xiàn)庫(kù)存不平開(kāi)發(fā)為了省事直接改了 inventory_balance 里的 quantity第二天對(duì)賬腳本跑出大量差異。原因臺(tái)賬被繞過(guò)流水里沒(méi)有對(duì)應(yīng)記錄庫(kù)存余額表變成了一個(gè)可以隨意篡改的數(shù)字對(duì)賬結(jié)果自然永遠(yuǎn)對(duì)不上。更麻煩的是時(shí)間一長(zhǎng)沒(méi)人記得哪些數(shù)據(jù)是手工改的整張表的數(shù)據(jù)可信度下降。解決任何庫(kù)存修正必須走庫(kù)存調(diào)整單調(diào)整單審核后在事務(wù)里更新臺(tái)賬、寫(xiě) ADJUST 流水。哪怕是初始化導(dǎo)入也要通過(guò)導(dǎo)入單完成?？梢员Ａ粢粋€(gè)“超級(jí)管理員”權(quán)限做數(shù)據(jù)修復(fù)但每一次修復(fù)都會(huì)留下流水和單據(jù)痕跡方便事后審計(jì)。我自己的習(xí)慣是工具可以寫(xiě)但工具生成的每一筆變更都必須有完整鏈路。6. 讓這套方案更抗打每日對(duì)賬、預(yù)警閾值與擴(kuò)展預(yù)留6.1 每日自動(dòng)對(duì)賬臺(tái)賬對(duì)流水、流水對(duì)單證對(duì)賬是庫(kù)存系統(tǒng)最樸素的護(hù)城河。我每天凌晨跑一遍賬把每行庫(kù)存的期初值加當(dāng)天流水發(fā)生額和期末值比對(duì)再把流水按 doc_no 匯總和單據(jù)表比對(duì)。任何一條對(duì)不上系統(tǒng)自動(dòng)生成差異記錄推給指定負(fù)責(zé)人。這個(gè)腳本不復(fù)雜但能兜住絕大多數(shù)人肉改數(shù)、漏單、重復(fù)扣減的問(wèn)題。6.2 預(yù)警閾值安全庫(kù)存與周轉(zhuǎn)提醒在 SKU 上配置 min_qty 和 max_qty低于最低值生成補(bǔ)貨建議高于最高值提示滯銷。閾值設(shè)置上我會(huì)結(jié)合最近三十天的日均銷量乘以采購(gòu)提前期來(lái)算而不是拍腦袋填一個(gè)固定數(shù)字。預(yù)警不在精在于穩(wěn)定觸發(fā)這樣運(yùn)營(yíng)才會(huì)認(rèn)真對(duì)待。6.3 擴(kuò)展預(yù)留批次、序列號(hào)與多計(jì)量單位方案里我刻意保留了擴(kuò)展位流水表已經(jīng)具備 doc_no 關(guān)聯(lián)能力未來(lái)加批次時(shí)只需要在 inventory_balance 和 inventory_flow 上增加 batch_no 字段按“倉(cāng)庫(kù) 庫(kù)位 SKU 批次”建唯一索引即可。序列號(hào)管理則需要單獨(dú)建一張表來(lái)記錄每個(gè)唯一碼的流轉(zhuǎn)狀態(tài)不放在臺(tái)賬里。多計(jì)量單位在商品中心處理庫(kù)存表始終以基礎(chǔ)計(jì)量單位記賬不做單位換算。這套方案我早期在某內(nèi)部系統(tǒng)里踩過(guò)一輪坑最大的教訓(xùn)就是庫(kù)存沒(méi)有玄學(xué)只有賬沒(méi)建對(duì)、順序沒(méi)走對(duì)、并發(fā)沒(méi)防對(duì)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取