开发者社区 > 博文 > 【积微成著】性能测试调优实战与探索(存储模型优化+调用链路分析)
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

【积微成著】性能测试调优实战与探索(存储模型优化+调用链路分析)

  • ne****
  • 2023-12-21
  • IP归属:北京
  • 4160浏览


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

    一、前言

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

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


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

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

    四、总结

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






    文章数
    1
    阅读量
    104

    作者其他文章