一、前言

性能测试之于软件系统，是保障其业务承载能力及稳定性的关键措施。以软件系统的能力建设为主线，系统能力设计工作与性能测试工作，既有先后之顺序，亦有相互之影响。以上，在性能测试的场景决策，架构分析、流量分析、压测实施和剖解调优等主要环节中，引发对于系统能力底盘夯实和测试策略改进的诸多思考。

在性能测试阶段，剖析系统能力实现及调优方案，探索更优解及性能测试策略的提升空间。

二、热点数据存储模型压测实战及思考

通过性能测试，推测 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 场景” 中的标准流程，已确认，存在进一步优化空间，并明确优化方案（如下图）。

四、总结

性能测试作为系统能力巩固升级的关键措施，通过对典型案例的陈述和思考，探索系统能力和性能测试策略的提升空间。确保核心系统链路稳定高效承载业务峰值流量，同时从容应对极端场景。

作者：京东物流 刘锐等

来源：京东云开发者社区 自猿其说 Tech 转载请注明来源