京东物流-技术与数据智能部-平台技术部（曹丽影、刘锐、豆道饶、刘梦雪、姜媛美、安甲舒、金鹏、陈翔、许旭睿）

一、前言

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

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

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

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

四、总结

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