作者：京東物流 尹昊喆

前言

本文總結庫存平臺穩定性建設中遇到的問題以及解決方案。感謝【金鵬】、【孫靜】、【陳瑞】同學在本文撰寫中提供的內容及幫助！

庫存平臺面臨的穩定性挑戰

庫存平臺為貨品流通鏈路提供全面的庫存管理服務，貫穿其整個訂單生命周期，是電商領域不可或缺的核心模塊。在平臺建設過程中，我們面臨了諸多穩定性方面的挑戰。

?

具體而言，存在以下問題：

1、業務流程繁多，不同流程共同訪問同一應用，容易相互影響。例如，銷售單庫存預占功能出現問題時，退供預占功能亦隨之失效。

?

?

2、業務流程復雜，修改易出錯。銷售單預占等流程，流程分支多、步驟多，新入職的員工需要至少一周的時間才能理解這些流程。對如此復雜的流程進行修改極易導致錯誤。

?

3、庫存數據的準確性要求極高。一旦某一貨品的庫存信息出現錯誤，可能導致該貨品后續的訂單都無法正常下單或無法履約。

?

4、數據庫熱點操作帶來的穩定性威脅。秒殺活動、直播促銷等業務場景，往往會出現短時間內多個訂單都去預占某一個或幾個商品庫存的情況。多個線程并發對同一個數據庫商品數據做庫存扣減時，數據庫中會加鎖來保障數據被正確操作。當商品數據足夠【熱】時，大量的鎖等待會引發性能問題，進而導致系統不可用，見下圖：

5、店鋪庫存高頻、大規模計算帶來的穩定性威脅。一個商家的庫存發生變動后，需要把商家庫存重新分配給商家名下的各個店鋪，這個分配過程計算量極大，容易把CPU打滿，進而影響所有服務

?

庫存平臺穩定性建設

為了應對庫存平臺所面臨的穩定性挑戰，除了通用的可用率可視化、限流等治理措施外，我們還結合庫存業務的特點，采取了以下穩定性建設。

流量拆分

我們識別到，庫存流量有以下幾個特點：

1、存在必須要重點保障的核心流量。銷售單庫存預占能力屬于物流核心流程，其目的是為京東物流倉配業務提供出庫單庫存校驗服務，從而避免訂單量超出庫存容量而錯誤地傳遞到倉庫管理系統（WMS）中，在接單鏈路中若庫存操作失敗則訂單接單失敗，造成公司大量的財產損失

2、存在一些計算量大又不需要實時處理的流量。如WMS出庫以后，需要回傳庫存出庫情況，這部分流量很高，但對處理實時性要求不高

3、存在一些明細行特別多的庫存批量操作。以銷售單庫存預占為例，絕大部分庫存操作批量大小在10個以內，但是也存在部分批量大小超過6000的情況。不同的批量大小，調用方需要有不同的超時配置，如批量大小在10個以內，超時時間配置為500毫秒；批量大小大于6000時，超時時間需要配置為50秒

?

基于流量的這些特點，我們對庫存流量拆分如下：

?

注：流量拆分使用不同的服務分組實現

?

灰度鏈路

針對庫存操作流程復雜且改動容易出錯的情況，我們在過往的上線過程中，通常會使用ducc編寫一個流程開關，逐步進行灰度放量。

然而，這種做法存在兩個主要問題：

1、維護成本較高。需求經過驗證后，仍需再次上線以移除不再使用的開關，但往往因疏忽而未能及時下線，導致代碼中充斥著冗余的開關，邏輯變得混亂。

2、容易引發線上問題。大型需求的改動點通常較多，需要在多個地方添加開關，稍有不慎便可能遺漏，從而導致線上問題頻發。

?

我們識別到，庫存業務通常在一個商家范圍內進行。因此，庫存操作的核心接口均包含以商家為單位的參數。在進行灰度驗證時，可以按商家單位進行灰度切量。基于這一特性，庫存系統構建了以商家為基礎的灰度鏈路。

?

相較于以往的灰度方法，灰度鏈路無需在每次需求變更時增加流程控制代碼，從而降低了線上出現問題的概率。

?

操作數量校驗

對于某一貨品的庫存操作，將變更一條或多條庫存記錄。例如，在依據渠道優先級進行出庫操作時，將優先扣減京東渠道的庫存，再扣減共享渠道的庫存。當某一貨品的操作涉及多條庫存記錄時，需為每條庫存記錄分配相應的操作數量。操作完成后，應為每條記錄生成變更記錄流水。

針對這個業務現狀，我們進行了庫存流水加和校驗：

?

?

數據庫熱點操作應對

當商家出售爆款商品時，會頻繁扣減特定庫存記錄。在操作數據庫的過程中，數據庫會對庫存記錄進行加鎖，并按順序執行這些扣減操作。這導致容器中積累了大量等待的線程和數據庫連接，一方面可能導致服務請求超時，另一方面，大量占用容器資源可能引發容器宕機，進而影響其他商品的庫存操作。

倘若采取粗暴的限流措施，將導致大量庫存扣減失敗，并且連非熱門商品也會受到波及，造成不良影響。

使用redis緩存解決熱點

我們的初版的解決方案是在緩存中添加庫存數據，利用緩存的高效性能來應對熱點問題。我們按商家的粒度逐步在灰度鏈路中進行流量切換，具體如下圖所示。：

通過此項優化，成功將熱點商品預占TPS從50提升到1200，提升了24倍。TP99降低到130ms，降低至原時長的4.3%（從3000ms到130ms）。

橙色部分為優化后的結果：

?

?

?

在切量過程中，我們發現了兩個問題：

1、數據庫與Redis數據存在不一致的情況。由于某些業務場景考慮不周全，導致數據庫與Redis數據出現不一致，而這些問題往往需要通過商家或下游的反饋才能被發現并修復。

2、部分關鍵客戶商家難以進行灰度切量。一些大型關鍵客戶商家在處理庫存時，存在定制化的特殊處理邏輯，使用緩存來支撐這些邏輯的成本較高且容易出錯。

?

解決數據庫與Redis數據不一致問題方案

從操作流程上保障數據庫與redis一致

操作流程上面臨的主要技術問題如下圖：

?初始化流程方案。使用 鎖定db庫存+redis事務來保障數據一致性。見下圖：

?數據同步流程。使用mq重試+任務系統兜底來保障同步能完成

數據庫、redis數據一致性校驗

庫存平臺每日執行數百萬次庫存操作，如何在不影響系統性能的同時及時發現數據不一致的情況，是一個需要仔細權衡的問題。我們采取了以下解決方案：

?

增加緩存流水

當發現有數據庫-redis數據不一致時，我們需要有數據來協助我們定位不一致問題發生的原因，所以在es中增加了redis緩存操作的流水記錄，如下圖：

數據庫、redis數據查詢、操作管理能力

我們開發了管理頁面，支持以商家、貨品、單據等維度來查詢并操作數據庫、redis數據，界面如下圖：

解決關鍵客戶商家難以使用redis緩存問題

一些大型關鍵客戶商家在處理庫存時，存在大量定制化的邏輯，在緩存中實現一次不僅成本高，還容易出現錯漏。針對這部分商家，我們采用了以下治理思路。

異步限流

設計思路：讓熱點不那么熱。通過減緩預占操作速度，從而降低熱點熱度，緩解庫存系統的性能壓力。見下圖：

?

熱點檢測、限流

設計思路：及時識別熱點庫存，對熱點庫存實施流量控制，從而確保系統的穩定性。

流量控制采用滑動窗口算法。實現原理：每當經過一個時間點，時間窗口即向前推進一個單位，計算該窗口內的請求數量。若請求數量超出預設限制，則拒絕處理請求；反之，則予以處理。

具體實現使用AOP切面編程，流程如下圖：

注：限流流程在try-catch中執行，中間除了【被限流異常】，別的異常都捕獲吞掉，防止影響正常邏輯

?

熱點限流告警示例：

店鋪庫存穩定性建設

商家通過入駐京倉來管理其線上與線下銷售渠道的庫存。京倉是一個綜合性的倉儲管理系統，它幫助商家有效地整合和管理其庫存資源。商家可以在京東POP店、京東自營VMI、唯品會、淘天、抖音、快手等線上平臺以及線下門店進行銷售。這種多渠道銷售模式不僅擴大了商家的市場覆蓋面，還提高了銷售效率。

為了防止超賣現象，商家需要確保線上與線下庫存的共享。這意味著商家必須實時更新庫存數據，確保所有銷售渠道都能看到最新的庫存信息。通過這種方式，商家可以避免因庫存信息不同步而導致的超賣問題，從而提升客戶滿意度和信任度。例如，如果一個商品在線上被售出，系統會立即更新庫存信息，確保線下門店不會再次銷售同一商品。

目前，已有75,821家商家入駐京倉，店鋪數量達到162,306家，實物1,785萬件，明細行數為9,309萬條。這些數據表明，京倉已經成為眾多商家管理庫存的重要平臺。

隨著商家接入量、計算場景的增加，系統計算量也隨之增大，常常使得容器CPU和數據庫CPU的負載過高，進而影響整個系統的穩定性且都是后知后覺，無法提前控量。當容器CPU的負載過高時，會導致對外提供的JSF服務的可用率降低。這不僅影響了用戶體驗，還可能導致商家的業務受到影響，為了保持系統的穩定性和性能，需要對系統進行優化和升級，同時加強監控和維護，確保系統能夠高效地運行。

?

前置動作

1、梳理出所有觸發計算的場景共25個觸發點庫存變化、低于安全水位、調整商品比例、調整店鋪維度比例、虛擬組套修改、固定值設置等。

2、從以上場景中又梳理出“殺傷力”最大的兩個計算場景分別是

店鋪比例調整：整個事業部下的所有SKU全量計算。

虛擬組套計算：由于虛擬組套規則的特殊性，單次計算會生成1.5W+條計算流水。

優化方案

CPU使用率治理

我們對店鋪維度比例調整場景，進行了提前發現并對該事業部進行提前限流，有效的解決了流量一下全打到應用服務器，導致CPU飆升的場景

?

效果：

JSF服務治理

通過日常OPS Review發現，當計算任務量激增時，整個系統的資源會被大量占用，導致對外服務響應時間變長，甚至出現服務中斷的情況。為了改善這一狀況，我們決定將計算功能和JSF功能進行分組隔離。這樣，計算任務和用戶界面操作可以分別在獨立的資源池中運行，互不影響。

?

效果

優化前：

優化后

虛擬組套治理

虛擬組套專為京倉來源的訂單設計，通過在ECLP中配置虛擬組套關系，實現JD商城下單時為一個套裝SKU，而ECLP接單及WMS出庫時則按原料SKU出庫的功能,給商家帶來了更靈活的銷售策略。

例如，組套SKU=1*原料1(20%)+2*原料2(20%)+1*原料3(20%)。通過組套關系可以看出，組套SKU的庫存量來源于原料。在進行組套計算時，需先根據店鋪維度比例或EMG分配比例計算出原料庫存，再依據組套規則分配給組套SKU，需進行二次計算。實際應用中，每個原料可以共享給多個組套，整個綁定關系呈現網狀結構，單次計算量會成倍增加(1W+)，占用更多計算資源，從而影響其他非組套商家的計算。

計算示例：

?

通過以上計算MQ拆分，并通過JMQ4進行限流，可以做到平滑計算，不會再出現重算量激增導致CPU一下打滿情況。

優化前：

優化后：

?

未來規劃

補充業務監控告警

當前庫存平臺的監控告警主要集中在接口層面，然而，接口的成功返回并不完全意味著業務處理已正常完成并落庫。因此，我們計劃引入更為全面的數據維度監控告警機制，以確保業務處理的完整性和準確性。

?

監控策略：以小時數據為單位進行對比，例如將2月28日9:00至10:00期間的預占成功與回傳成功數量，與2月21日同一時間段的數據進行對比。當差異比例超過預設閾值時，觸發告警。

告警觸發條件：定時觸發，每小時的第五分鐘執行一次，例如在10:05觸發，對比9:00至10:00的數據。

數據來源：通過查詢ES或大數據平臺進行對比，以避免對線上核心業務造成影響。

數據庫-redis不一致比對工具

當前接收到數據庫與Redis不一致的告警后，我們采取人工查詢數據庫流水及Redis流水并進行比對的方式，以查找不一致的原因。由于一個貨品在特定時間段內的流水記錄可能極為繁多，這一比對過程耗時且費力。為此，我們計劃開發一款不一致比對工具，實現自動化分析不一致的原因，并輸出導致不一致的具體單據。

審核編輯 黃宇