【积微成著】性能测试调优实战与探索(存储模型优化+调用链路分析)| 京东物流技术团队

原创
01/02 11:18
阅读数 33

一、前言

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

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

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

通过性能测试,推测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 转载请注明来源

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部