一、前言

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

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

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

通过性能测试，推测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密度和复杂度需要，自动化快速构建组装？需要在现有压测框架基础上，开发扩展功能，以支撑从基础数据到复杂单据的一键快速初始化构造能力，降低复杂场景构建难度，提升测试工作效率。