一、前言

性能測試之于軟件系統(tǒng)，是保障其業(yè)務(wù)承載能力及穩(wěn)定性的關(guān)鍵措施。以軟件系統(tǒng)的能力建設(shè)為主線，系統(tǒng)能力設(shè)計工作與性能測試工作，既有先后之順序，亦有相互之影響。以上，在性能測試的場景決策，架構(gòu)分析、流量分析、壓測實施和剖解調(diào)優(yōu)等主要環(huán)節(jié)中，引發(fā)對于系統(tǒng)能力底盤夯實和測試策略改進的諸多思考。

在性能測試階段，剖析系統(tǒng)能力實現(xiàn)及調(diào)優(yōu)方案，探索更優(yōu)解及性能測試策略的提升空間。

?

二、熱點數(shù)據(jù)存儲模型壓測實戰(zhàn)及思考

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

數(shù)據(jù)架構(gòu)升級后，SKU庫存預占效率（TPS）提升2300%↑。

測試驅(qū)動，結(jié)合系統(tǒng)實現(xiàn)，論證緩存預熱的必要性，并借助大數(shù)據(jù)分析，探索科學的緩存預熱及保溫策略。

結(jié)合新業(yè)務(wù)模式，思考更加科學的測試數(shù)據(jù)構(gòu)建思路和測試過程提效方案。

?

1、壓測場景

庫存預占，是指在訂單接單環(huán)節(jié)，為單據(jù)提供SKU庫存短暫預留。物流倉配訂單接單環(huán)節(jié)，會發(fā)起SKU維度的庫存預占行為。

庫存中心通過“庫存預占主應(yīng)用”中的預占接口，對外提供SKU庫存預占標準能力。主要通過“庫存扣減邏輯管控及數(shù)據(jù)庫層交互”、“緩存層交互”，以及“任務(wù)調(diào)度”三個關(guān)鍵應(yīng)用，承載庫存邏輯計算及存儲層交互能力。

數(shù)據(jù)模型視角，對預占能力實現(xiàn)分為兩種：

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

?批次庫存預占直接由數(shù)據(jù)庫承載。

當大促倉配單量進入爆發(fā)期，熱點SKU預占請求快速增長，且?guī)齑骖A占請求直達數(shù)據(jù)庫，系統(tǒng)TP99會出現(xiàn)跳點甚至持續(xù)升高，嚴重情況下造成接單超時。

以上，計劃針對性構(gòu)造壓測場景及數(shù)據(jù)模型，確認系統(tǒng)的峰值承載能力及調(diào)優(yōu)策略的有效性。

2、首壓及分析

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

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

?壓測過程及結(jié)論

?在QPS=50時，系統(tǒng)可穩(wěn)定支撐庫存預占業(yè)務(wù)（TP99≈100ms）。

?“庫存預占”主應(yīng)用：CPU使用率≤15%，內(nèi)存使用率≤35%

?“庫存扣減邏輯管控及數(shù)據(jù)庫層交互”應(yīng)用：CPU使用率≤18%，內(nèi)存使用率≤65%

?數(shù)據(jù)庫：CPU使用率≤7.8%（無慢SQL）

?基于當前的系統(tǒng)性能體現(xiàn)，具備持續(xù)加壓的條件。

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

“庫存預占”主應(yīng)用 TP99+TPS趨勢

“庫存預占”主應(yīng)用 硬件資源趨勢

數(shù)據(jù)庫 關(guān)鍵指標（CPU）

數(shù)據(jù)庫 關(guān)鍵指標（慢SQL）

數(shù)據(jù)庫 關(guān)鍵指標（內(nèi)存）

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

3、調(diào)優(yōu)及復壓

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

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

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

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

庫存中心-庫存預占場景 系統(tǒng)架構(gòu)簡圖

庫存中心-庫存變化監(jiān)控機制簡圖

?復壓結(jié)論

?完成數(shù)據(jù)架構(gòu)升級及熱點SKU緩存預熱后，初始QPS=1100并以100遞增，TPS上探至1200時，TP99≈130ms，系統(tǒng)可穩(wěn)定支撐批次庫存預占業(yè)務(wù)。

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

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

“庫存預占”主應(yīng)用 TP99+TPS趨勢

“庫存預占”主應(yīng)用 硬件資源趨勢

數(shù)據(jù)庫 關(guān)鍵指標(CPU)

數(shù)據(jù)庫 關(guān)鍵指標（慢SQL）

數(shù)據(jù)庫 關(guān)鍵指標（內(nèi)存）

Redis集群 關(guān)鍵指標

4、系統(tǒng)健壯性思考

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

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

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

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

系統(tǒng)整體可平穩(wěn)承載流量，同時緩存命中率曲線，有一定的提升空間

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

?緩存預熱實踐：通過對某客戶大促前集中采購期及大促節(jié)點SKU品類重合度分析，發(fā)現(xiàn)以下規(guī)律

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

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

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

大促主要環(huán)節(jié) SKU品類重合度分析

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

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

?系統(tǒng)優(yōu)化思路

?靜態(tài)方案：單量高峰期期間，延長Key效期，覆蓋大促關(guān)鍵環(huán)節(jié)間隔。

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

5、測試策略改進思考

?場景拓展

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

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

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

?

三、無效調(diào)用量分析、識別及調(diào)優(yōu)實戰(zhàn)

在性能測試的流量分析階段，結(jié)合業(yè)務(wù)場景調(diào)研，前置識別性能瓶頸疑點。

推動排查及調(diào)整核心鏈路調(diào)用邏輯后，在標定的業(yè)務(wù)窗口期，核心接口調(diào)用總量降低60%↓。

深入細分業(yè)務(wù)場景，推演潛在的調(diào)優(yōu)空間。

1、背景

物流系統(tǒng)在訂單出庫后，由 訂單明細查詢應(yīng)用，提供訂單及其關(guān)聯(lián)包裹明細信息的對外查詢能力。主要由外部系統(tǒng)（Top2量級調(diào)用方：接入回傳67%、履約回傳11%）調(diào)用，在單據(jù)出庫后，輸出出庫貨品的數(shù)量和包裹詳情等訂單基礎(chǔ)信息。

關(guān)鍵（Top2）調(diào)用方拓撲

2、場景調(diào)研及疑點識別

?場景調(diào)研及風險預判（生產(chǎn)流量分析）

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

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

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

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

最近一次促銷期 關(guān)鍵應(yīng)用調(diào)用量

2023年10.12 關(guān)鍵應(yīng)用調(diào)用量

?調(diào)用鏈粗篩

?倉配出庫單據(jù)維度，履約回傳應(yīng)用，向訂單系統(tǒng)推送出庫明細時，會調(diào)用倉明細查詢接口。

?接入回傳應(yīng)用，在回傳訂單信息時，會調(diào)用倉明細查詢接口。

?履約狀態(tài)回傳調(diào)用峰值 / 接入回傳調(diào)用峰值 ≈ 1:9，接入回傳調(diào)用峰值明顯偏大，逐步鎖定疑點系統(tǒng)（接入回傳應(yīng)用）。

?疑點深剖

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

?技術(shù)架構(gòu)層面，接入回傳應(yīng)用在未判斷訂單狀態(tài)情況下，調(diào)用目標接口。導致單據(jù)在未出庫且沒有出庫明細時，發(fā)生大量無效調(diào)用。

?同時發(fā)現(xiàn)，因AB測試環(huán)境別名配置錯誤，導致生產(chǎn)流量誤疊加。

3、調(diào)優(yōu)策略

?調(diào)用邏輯調(diào)整

?“I” 業(yè)務(wù)場景訂單回傳階段，如單據(jù)狀態(tài)為出庫前，不發(fā)起“訂單包裹明細查詢接口”調(diào)用，剔除無效查詢。

?根據(jù)最終的回傳內(nèi)容（是否需要明細信息），判斷調(diào)用的必要性，剔除非必要查詢。

?調(diào)整AB測試環(huán)境別名配置，避免測試流量對生產(chǎn)環(huán)境產(chǎn)生非必要壓力。

優(yōu)化前接入回傳應(yīng)用邏輯

優(yōu)化后接入回傳應(yīng)用邏輯

4、調(diào)優(yōu)效果

?相對調(diào)優(yōu)前（10.12），“接入回傳應(yīng)用” 調(diào)用總量降低60%↓（前：2397252500 后：925890100），峰值調(diào)用量降低64%↓（前：5921500 后：2121800）。

下圖分別為調(diào)整前、后調(diào)用量分布，用以對比

5、性能風險前置識別

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

6、OpsReview常態(tài)化

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

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

?定制化邏輯排查：系統(tǒng)內(nèi)非標業(yè)務(wù)存在較多的定制化邏輯，有必要針對特殊邏輯排查無效查詢風險。

7、潛在調(diào)優(yōu)空間推演

?基于測試經(jīng)驗，經(jīng)過業(yè)務(wù)場景梳理，發(fā)現(xiàn) “I場景” 下存在細分的非標定制化流程，以及與 “I場景” 并列的 “P場景” 標準流程。

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

四、總結(jié)

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

審核編輯 黃宇