一、前言

性能測試之于軟件系統，是保障其業務承載能力及穩定性的關鍵措施。以軟件系統的能力建設為主線，系統能力設計工作與性能測試工作，既有先后之順序，亦有相互之影響。以上，在性能測試的場景決策，架構分析、流量分析、壓測實施和剖解調優等主要環節中，引發對于系統能力底盤夯實和測試策略改進的諸多思考。

在性能測試階段，剖析系統能力實現及調優方案，探索更優解及性能測試策略的提升空間。

?

二、熱點數據存儲模型壓測實戰及思考

通過性能測試，推測SKU庫存預占場景，在不同存儲模式下的性能瓶頸及風險。

數據架構升級后，SKU庫存預占效率（TPS）提升2300%↑。

測試驅動，結合系統實現，論證緩存預熱的必要性，并借助大數據分析，探索科學的緩存預熱及保溫策略。

結合新業務模式，思考更加科學的測試數據構建思路和測試過程提效方案。

?

1、壓測場景

庫存預占，是指在訂單接單環節，為單據提供SKU庫存短暫預留。物流倉配訂單接單環節，會發起SKU維度的庫存預占行為。

庫存中心通過“庫存預占主應用”中的預占接口，對外提供SKU庫存預占標準能力。主要通過“庫存扣減邏輯管控及數據庫層交互”、“緩存層交互”，以及“任務調度”三個關鍵應用，承載庫存邏輯計算及存儲層交互能力。

數據模型視角，對預占能力實現分為兩種：

?事業部維度庫存預占主要通過Redis緩存層承載。

?批次庫存預占直接由數據庫承載。

當大促倉配單量進入爆發期，熱點SKU預占請求快速增長，且庫存預占請求直達數據庫，系統TP99會出現跳點甚至持續升高，嚴重情況下造成接單超時。

以上，計劃針對性構造壓測場景及數據模型，確認系統的峰值承載能力及調優策略的有效性。

2、首壓及分析

?壓測目標：“庫存預占主應用”下的“預占接口”，在數據庫承載熱點SKU預占請求模式下，探索目標TP99（≤3000ms）可承載的峰值流量，并驗證調優后的峰值承載能力（目標 TP99≤500ms）。

?壓測方案：單個熱點SKU持續發壓預占，發壓起始QPS=10，并以QPS+10遞增，探索可承載請求的性能上限。

?壓測過程及結論

?在QPS=50時，系統可穩定支撐庫存預占業務（TP99≈100ms）。

?“庫存預占”主應用：CPU使用率≤15%，內存使用率≤35%

?“庫存扣減邏輯管控及數據庫層交互”應用：CPU使用率≤18%，內存使用率≤65%

?數據庫：CPU使用率≤7.8%（無慢SQL）

?基于當前的系統性能體現，具備持續加壓的條件。

?以QPS+10遞增加壓至60時，TP99在2分鐘左右快速增長至7000ms，“庫存預占”主應用TPS≤60，預判系統能力達到瓶頸，停止加壓。

“庫存預占”主應用 TP99+TPS趨勢

“庫存預占”主應用 硬件資源趨勢

數據庫 關鍵指標（CPU）

數據庫 關鍵指標（慢SQL）

數據庫 關鍵指標（內存）

?瓶頸預判：單據維度的庫存預占是以先查（可用庫存）后寫（預占庫存）的方式進行，在對熱點SKU高頻次下單過程中，數據庫會對該行記錄長時間持續讀寫，數據庫層面會通過行鎖機制保證單筆交易的原子性，行級鎖引發的鎖競爭大概率會導致系統處理能力達到瓶頸，制約系統的執行效率。同時從應用層到存儲層，未出現硬件資源瓶頸，排除硬件資源不足的影響。

3、調優及復壓

?存儲層改造（見 庫存中心-庫存預占場景 系統架構簡圖）：經首輪壓測及分析，為解決已知性能瓶頸，從數據架構層面，將批次庫存預占由數據庫直接承載請求壓力，升級為由Redis緩存主要承載請求壓力。利用Redis高性能吞吐能力，解決并發場景下的數據讀寫效率問題，由Redis前置承載熱點商品的主要流量。

?一致性保障（見 庫存中心-庫存變化監控機制簡圖）

?為確保緩存層與數據庫層數據一致性，在緩存命中的情況下，通過建立調度任務或MQ方式異步回寫數據庫。

?在緩存擊穿時，通過先讀（數據庫）后寫（Redis）再反饋（API）預占結果，之后異步回寫數據庫，確保數據一致性。

庫存中心-庫存預占場景 系統架構簡圖

庫存中心-庫存變化監控機制簡圖

?復壓結論

?完成數據架構升級及熱點SKU緩存預熱后，初始QPS=1100并以100遞增，TPS上探至1200時，TP99≈130ms，系統可穩定支撐批次庫存預占業務。

?當TPS上探至1300時，TP99出現明顯波動（毛刺≈420ms），且“緩存層交互”應用CPU占用率飆升至90%+，核心鏈路穩定性劣化，停止加壓。

?相較數據庫承載模式，緩存化升級后，TP99滿足預期（≤500ms），TPS承載能力大幅提升2300%=(1200-50)/50。

“庫存預占”主應用 TP99+TPS趨勢

“庫存預占”主應用 硬件資源趨勢

數據庫 關鍵指標(CPU)

數據庫 關鍵指標（慢SQL）

數據庫 關鍵指標（內存）

Redis集群 關鍵指標

4、系統健壯性思考

?全量緩存的弊端：供應鏈模式中的不同行業，SKU品類生命周期存在較大差異（如服飾行業≈3個月），全量緩存模式會導致Redis中存在大量無效品類，資源消耗膨脹不可控，增加資源成本，有必要設計更有效的緩存方案。

?緩存預熱及保溫的必要性：緩存命中率，與預熱機制和保溫策略緊密相關。

?必要性：常規大促節奏，起售期會觸發首次緩存初始化，促銷品類與日常銷售品類的重合度，決定了首次緩存擊穿的概率。目前的Key有效期=7天，大促起售期→開門紅→高峰期間隔均大于7天，缺少必要的保溫策略，會增加下個促銷節點前緩存失效的可能性。

大促開門紅至11.11 緩存命中率趨勢

系統整體可平穩承載流量，同時緩存命中率曲線，有一定的提升空間

?預熱思路：如何盡可能保持在大促等特定時段的緩存有效性，提升緩存命中率（降低擊穿概率），可通過前置的多維度分析調研，包括但不限于基于大數據的大促前集中采購品類分布分析、歷次大促及關鍵節點促銷品類密度及分布分析 以及 關鍵客戶促銷計劃調研等方式，結合技術手段，前置預判、預熱及保溫。

?緩存預熱實踐：通過對某客戶大促前集中采購期及大促節點SKU品類重合度分析，發現以下規律

?集采入視角：大促集采期SKU品類，相對開門紅品類重合度≈69%，相對11.11品類重合度≈75%。

?銷售出視角：起售期SKU品類，相對開門紅重合度≈94%，開門紅相對11.11品類重合度≈75%。

?以上數據證明，通過在開門紅以及11.11大促等關鍵促銷節點前，將集采期及前一促銷期的SKU可用庫存數據，進行緩存預熱，有助于提升預占請求的緩存命中率。

大促主要環節 SKU品類重合度分析

?異常場景識別：庫存場景對數據三性（準確性、及時性、完整性）要求較高，在數據庫與緩存的雙向同步過程中，需避免因一致性問題引發的業務異常。

?超賣異常識別：大促單量峰值期，為保護主數據庫安全，通過緩存同步限流減緩主庫壓力，造成緩存至數據庫同步延遲，同一SKU在數據庫層未及時扣減，如此時疊加緩存Key到期情況，接口直接返回MySQL數據，可能會引發超賣業務異常。

?系統優化思路

?靜態方案：單量高峰期期間，延長Key效期，覆蓋大促關鍵環節間隔。

?動態方案：增加熱點SKU緩存效期延時策略，Key到期T-1天，日均預占請求量大于1的SKU，自動延長Key有效期。

5、測試策略改進思考

?場景拓展

?直播電商模式主流化趨勢強勁（2023年前三季度全國直播電商銷售額達1.98萬億元，增長60.6%，占網絡零售額的18.3%，直播電商拉動網零增速7.7個百分點），相較傳統電商，其限時促銷模式疊加社交傳播擴散屬性，單品瞬時流量大，不同促銷場次品類重合度更低，促銷頻次高，對系統性能提出了不同的要求。

?反推性能測試策略，從平臺視角出發，需要盡可能提升選用SKU的多樣性，同時降低壓測單次請求SKU的品類重合度，識別真實復雜場景下的性能隱患。

?效率提升：復雜場景的倉配訂單性能測試工作，需要前置基礎數據的大量儲備（商品、庫存），以及高復雜度接口請求數據準備。如何確保商品和庫存等基礎數據快速就緒？同時下單請求的報文體根據SKU密度和復雜度需要，自動化快速構建組裝？需要在現有壓測框架基礎上，開發擴展功能，以支撐從基礎數據到復雜單據的一鍵快速初始化構造能力，降低復雜場景構建難度，提升測試工作效率。

?

三、無效調用量分析、識別及調優實戰

在性能測試的流量分析階段，結合業務場景調研，前置識別性能瓶頸疑點。

推動排查及調整核心鏈路調用邏輯后，在標定的業務窗口期，核心接口調用總量降低60%↓。

深入細分業務場景，推演潛在的調優空間。

1、背景

物流系統在訂單出庫后，由 訂單明細查詢應用，提供訂單及其關聯包裹明細信息的對外查詢能力。主要由外部系統（Top2量級調用方：接入回傳67%、履約回傳11%）調用，在單據出庫后，輸出出庫貨品的數量和包裹詳情等訂單基礎信息。

關鍵（Top2）調用方拓撲

2、場景調研及疑點識別

?場景調研及風險預判（生產流量分析）

?對“訂單包裹明細查詢接口”進行調用量趨勢分析，取樣23年10.12 06:30~23:00（流量分析期），環比最近一次促銷同時段（最近一次大促請求高峰期），Top2調用方峰值調用總量激增305%。

?基于前期調研，從調用量看，常規情況下倉庫出庫能力均值≈400000單/分鐘，倉庫出庫高峰時段為每日08:00~18:00，倉出庫次數:“訂單包裹明細查詢接口”峰值調用量≈1:10為“常規比例”。

?通過對10月12日線上數據觀測，倉出庫次數:“訂單包裹明細查詢接口”調用峰值（400000/6532200）≈1:16，相較“常規比例”偏差較大。

?以上，通過生產流量分析工作，識別出在倉庫出庫高峰時段，“訂單包裹明細查詢接口” 調用量存在疑點，并進一步深入分析。

最近一次促銷期 關鍵應用調用量

2023年10.12 關鍵應用調用量

?調用鏈粗篩

?倉配出庫單據維度，履約回傳應用，向訂單系統推送出庫明細時，會調用倉明細查詢接口。

?接入回傳應用，在回傳訂單信息時，會調用倉明細查詢接口。

?履約狀態回傳調用峰值 / 接入回傳調用峰值 ≈ 1:9，接入回傳調用峰值明顯偏大，逐步鎖定疑點系統（接入回傳應用）。

?疑點深剖

?經深入排查，首先確認前期對異常流量和疑點系統的判斷基本準確。

?技術架構層面，接入回傳應用在未判斷訂單狀態情況下，調用目標接口。導致單據在未出庫且沒有出庫明細時，發生大量無效調用。

?同時發現，因AB測試環境別名配置錯誤，導致生產流量誤疊加。

3、調優策略

?調用邏輯調整

?“I” 業務場景訂單回傳階段，如單據狀態為出庫前，不發起“訂單包裹明細查詢接口”調用，剔除無效查詢。

?根據最終的回傳內容（是否需要明細信息），判斷調用的必要性，剔除非必要查詢。

?調整AB測試環境別名配置，避免測試流量對生產環境產生非必要壓力。

優化前接入回傳應用邏輯

優化后接入回傳應用邏輯

4、調優效果

?相對調優前（10.12），“接入回傳應用” 調用總量降低60%↓（前：2397252500 后：925890100），峰值調用量降低64%↓（前：5921500 后：2121800）。

下圖分別為調整前、后調用量分布，用以對比

5、性能風險前置識別

?壓測實施階段不是發現性能隱患的唯一階段，如果有能力在流量分析階段識別性能風險并推動論證，問題發現越早，風控代價（資源）越小，質量風險越低。

6、OpsReview常態化

?流量異動觀測：流量分析及性能風險識別，需要結合實際的生產運營特征，以及接口的關鍵調用鏈，定義系統調用量的普遍規律。被調用方有必要不斷積累識別調用來源和常規量級，盤點外部調用策略，在調用量出現異動時，排查風險。

?編碼規范：對于接口調用邏輯，有必要抽象為標準方法，避免團隊協同開發過程中出現因人而異的Coding差異，降低無效查詢發生概率。

?定制化邏輯排查：系統內非標業務存在較多的定制化邏輯，有必要針對特殊邏輯排查無效查詢風險。

7、潛在調優空間推演

?基于測試經驗，經過業務場景梳理，發現 “I場景” 下存在細分的非標定制化流程，以及與 “I場景” 并列的 “P場景” 標準流程。

?聯動研發深入分析 “I場景” 中的非標定制化流程 以及 “P場景” 中的標準流程，已確認，存在進一步優化空間，并明確優化方案（如下圖）。

四、總結

性能測試作為系統能力鞏固升級的關鍵措施，通過對典型案例的陳述和思考，探索系統能力和性能測試策略的提升空間。確保核心系統鏈路穩定高效承載業務峰值流量，同時從容應對極端場景。

審核編輯 黃宇