2. 大促压测前的最后一周，我是这样把问题暴露在演练场的
淘客返利APP这类业务，平时跑得挺稳，流量一冲高就原形毕露：领券接口超时、订单回调积压、返利结算延迟。这次大促压测，我们就是用JMeter把全链路真实跑了一遍，从脚本设计到GC日志分析，把平时藏在角落里的瓶颈一个个抠了出来。这篇文章把整个过程重新整理了一遍，重点说清楚怎么压、怎么定位、怎么调，以及哪些坑值得后来者绕开。
做这件事的人，一定都清楚这种处境：大促前压测是最后一个能“优雅地发现问题”的窗口。比起线上事故再去救火，压测阶段暴露问题成本低得多。所以这篇内容适合正在准备大促的技术人阅读，不管你是做压测方案设计、还是负责架构调优，都可以从中找到可直接落地的思路。
2. 项目背景与压测目标设计
2.1 业务链路与风险点初判
淘客返利APP的链路比普通电商App更绕一些。用户进来先登录，然后浏览商品，领券，跳转到电商平台下单。但真正属于我们服务的核心链路是这个订单同步回调、返利计算、返利入账、用户提现。
整条链路是典型的前端高并发读、后端异步写模式。领券和下单是高并发写入口，订单回调和返利计算则是异步消费，中间隔了消息队列。
大促时间点，所有人同时进来领券、比价、下单，流量会在几个核心接口上聚成尖峰。梳理完业务链路之后，我们列出了几个明显的风险点：
- 领券接口是短时高并发写热点，所有请求都集中在一个Redis key上做库存扣减。
- 订单回调消息在返利计算环节存在重复消费与顺序性问题，瞬时积压会导致返利入账延迟。
- 用户侧查询返利余额的接口涉及多表关联查询和聚合计算，大促期间查询放大效应明显。
- 提现申请需要操作资金账户，在P0级别业务中属于高风险接口，一旦出问题影响信任感。
这几个风险点决定了压测方案不能按“单接口压测”来做，必须搭建全链路场景，把不同接口的真实流量模型串联起来。
2.2 压测目标与人资安排
这条压测方案定了从业务预估到技术指标拆解的完整目标。
业务侧预估大促当天峰值UV约为平时的8到10倍，日常峰值QPS是5000，所以压测目标定为5万QPS。在拆解到具体接口时，不同接口的比例根据历史流量模型估算，领券接口约占总请求的15%，商品浏览约40%，订单回调约20%，余额查询约15%，提现申请约10%。
技术指标上我们定了三个必须满足的硬指标：
| 指标 | 目标值 |
|---|---|
| 核心接口成功率 | 不低于99.9% |
| 核心接口P99响应时间 | 不超过500ms |
| 服务器负载 | 应用服务器CPU不高于70%，内存使用率不高于80% |
人资安排上，压测执行组、监控组和业务保障组同步到位。执行组负责JMeter脚本开发和压力发起，监控组负责观察Grafana dashboard和服务端指标，业务保障组负责对大促规则和返利计算逻辑进行正确性验证。
2.3 环境部署与数据准备
压测环境我们用了四台8核16G的云主机部署应用，两台数据库实例，一个一主两从的Redis集群，以及一套与线上配置一致的消息队列环境。压测数据准备同步做了三件事。
商品数据准备了20万条，分布在不同的类目和价格带。优惠券池子做了200个券批次，每个批次有不同的库存上限和有效期。用户数据准备了50万个测试账号，每个账号有各自的返利等级、历史订单和余额数据。这些数据量不算大，但足以让压测链路覆盖到大部分业务分支。
在数据隔离性上，压测环境是独立的一套，与生产完全隔离。但数据库里的一些聚合统计表，为了压出真实性能，相关数据量是按生产环境的量级预先生成好的，比如订单流水表、返利明细表，都提前灌入了上亿行数据。这一步如果省略，压出来的索引性能没有任何参考价值。
3. JMeter全链路压测方案设计与脚本实现
3.1 链路拆解与脚本结构
全链路压测不能把接口平铺着压一遍，必须按照用户的真实操作顺序来编排脚本。我们最终把业务链路拆成了六个步骤：
- 登录接口获取用户token
- 浏览商品列表与详情
- 领取指定批次优惠券
- 模拟下单请求（下单跳转在外部平台，压测环境用Mock替代）
- 查询返利余额
- 提交提现申请
这六个步骤不是每条链路都要全部走完，我们根据业务比例设计了三个线程组模型。第一个线程组是主链路，按6步完整执行；第二个线程组是领券和浏览的高频组合，模拟大量用户只领券不走下单流程；第三个线程组专门压异步回调接口和返利计算接口，用于验证消息消费能力。
每个线程组里，登录这一步做了独立处理，登录获取的token通过JMeter的setProperty写入全局属性，后续线程直接读取，避免每个线程都重复进行登录操作而给压测带来额外的无用开销。这个细节直接影响压测的真实性，登录接口根本不会在大促高峰成为瓶颈，把它放在循环里反而会稀释对核心链路的压力。
3.2 参数化、关联与断言的关键细节
JMeter脚本里最容易忽视的是数据分布问题。所有用户都用同一个商品ID、同一个券批次去压，压出来的是缓存热点结果，而不是系统真实能力。
我们的做法是用CSV文件做数据驱动。商品ID文件按行排列，每个线程按顺序或随机读取，券批次参数同样通过CSV关联用户等级和可用券批次。为了模拟真实用户行为，领券接口的请求体里同时带上用户ID和券批次号，数据库里提前为这些用户建立了相应的领取资格。
关联部分，登录响应里的token字段用JSON提取器提取后存入JMeter变量，后续接口在HTTP Header中以Authorization请求头携带。订单回调接口在压测中接收的是一个模拟报文，我们提前把真实的回调报文结构和字段顺序确认好，确保Mock数据与生产环境的数据结构完全一致。
断言的使用要克制。我们在所有核心接口上加了响应码200级断言，在关键业务数据上，比如领券成功标志和余额查询返回数值，使用JSONPath断言。其他地方没有加额外的断言，断言过多会消耗JMeter本机的CPU，导致压测结果失真。
3.3 用户模型与梯度加压节奏
真正压测时，直接把线程数拉到最大去压，除了把系统压崩掉之外得不到任何有效数据。我们采用的是阶梯加压模型。
从1000个虚拟用户开始跑，每两分钟增加1000用户，同时观察服务端吞吐量和响应时间曲线。线程组的配置里，Ramp-Up时间设置为120秒，持续时间根据测试场景控制在20到30分钟。每个压力阶段记录一组数据，包括当前活跃线程数、聚合报告中的QPS、平均响应时间、P99响应时间以及服务端的CPU和内存使用率。
这样做的原因在于：不同的并发量对应着系统不同的运行阶段。低并发时系统处于线性扩展期，响应时间基本稳定；中并发时资源开始出现争用，RT开始抬升；高并发时系统进入瓶颈期，某些组件先被打穿。只有梯度加压才能准确定位到系统从健康到不健康的拐点，这个拐点数据是后续容量评估的重要依据。
压测评审时，我们有同事提出直接压到10万QPS看系统能扛多少，被我拦下了。预估峰值是5万，压到7万验证余量就够了，超出实际业务模型的加压只会浪费时间在无意义的调优上。
4. 瓶颈定位：从表象到根因的排查路径
4.1 第一轮压测：领券接口的服务端异常
梯度压测进行到4000并发时，Grafana上的监控曲线开始出现异常。领券接口的成功率从99.9%跌到了98.5%，平均响应时间从80ms拉高到2.8秒，P99已经突破3秒。其他接口的指标基本稳定，只有领券接口出现了明显的性能塌方。
先确认是不是压测端自身的问题。压测机CPU已经到70%左右，但还没打满。JMeter自身的GC也正常。再登录应用服务器看负载情况，四台应用服务器的CPU利用率分别是55%、62%、68%、72%，负载并未打满。
问题指向被压的组件本身。领券接口的调用链涉及Redis扣减库存、数据库插入用户券包、MQ推送领券消息三个环节。任何一个环节卡住，整体RT就会跟着飙升。我们决定从调用链的实时链路追踪数据下手定位。
4.2 线程、CPU、内存三维排查
登录应用服务器，用top命令看进程状态，发现所有应用进程的CPU使用率集中在GC线程和Netty业务线程组上。进一步用jstack dump线程现场，发现大量业务线程阻塞在Redis连接池获取连接的等待上。
这有些出乎意料。我们用的Redis客户端默认连接池最大连接数是8，单机连接数显然不够用。但再深挖一层，发现即使连接池扩容之后，依然存在排队。查看Redis服务器本身的监控，发现有一个key的访问频率异常之高，单节点CPU已经被ping到98%以上，其他两个从节点几乎空闲。
这就是典型的热点key问题。大促期间有个爆款券批次集中放量，所有用户领券都先命中同一个Redis key。Jedis或Lettuce客户端对这个key的访问全部落到一个分片节点上，单节点CPU最先被打穿。
排查进程发现瓶颈不只在这一处。数据库侧同样有异常，主库的活跃连接数持续打满连接池上限。连接池配置里最大连接数是20，监控显示连接等待时间平均在1.2秒。慢查询日志里发现两条SQL特别扎眼，一条是查询用户返利明细的联表SQL，走了全表扫描；另一条是插入券包时的唯一索引冲突检测，在并发插入时大量重试。
4.3 数据库与缓存层面的问题确认
对慢SQL进行分析后发现，返利明细查询语句只对用户ID建了索引，但查询条件同时带上了时间范围和状态字段，导致在没有命中用户ID前缀的情况下走了全表扫描。大促期间这个SQL被高频调用，进一步放大了数据库的压力。索引优化方向是增加一个用户ID加状态字段的复合索引，让查询能直接命中索引覆盖范围。
连接池打满的问题，是连接池最大连接数配置和数据库max_connections参数之间的不匹配导致的。数据库max_connections是200，连接池最大连接数如果全部占满，再加上其他业务组的连接，就把数据库连接数吃完了。调整时把连接池上限提到80，数据库max_connections同步调高到500，避免因单组连接池配置不当导致整个数据库不可用。
缓存层面的问题除了热点key，还暴露了缓存穿透风险。压测期间有大量查询请求带着不存在的用户ID访问余额查询接口，每一个请求都直接穿透到数据库。排查后确认是测试数据集里的账号没有被正确初始化，但这个问题同样值得注意，生产环境的异常流量也可能产生类似请求。处理方式是接口层加布隆过滤器，对恶意或无效请求提前拦截。
瓶颈定位到这里，已经形成了几个明确的优化项。将每一项问题先记录到压测问题清单里，再逐一修复并复测。
5. JVM GC调优实战：从原理到参数落地
5.1 压测暴露出的GC问题
第一轮压测结束后，我们汇总了应用服务器的JVM监控数据。在4000并发持续压测期间，四台应用服务器的Full GC次数均超过120次，平均每次Full GC的STW时长为824ms，最差有一次达到了1.8秒。这个数据意味着，在压测高峰的20分钟里，每台机器平均每隔10秒就发生一次上秒级的全局停顿。停顿期间所有业务线程全部暂停，接口RT自然跟着飙升。
通过GC日志看到，堆内存配置的是默认的最大堆4GB（物理内存16G），运行时的新生代和老年代比例是1比2。压测时对象产生速率非常快，Eden区频繁被打满，触发Young GC。但真正致命的是老年代空间被短生命周期的大对象快速填满，直接触发了Full GC，而Full GC又回收不掉这些对象。
这些大对象从哪来的？后来分析后发现，领券和返利计算这两个环节在请求处理过程中创建了大量中间DTO对象，同时一些工具类的静态List缓存了过期的用户券包数据，导致这些对象无法被回收。老年代空间持续膨胀，最终压垮了老年代。
5.2 堆配置与GC选型的前期评估
调整前先做了评估。默认GC用的是Parallel Scavenge加Parallel Old的组合，这个组合在追求吞吐量的批量处理场景中表现很好，但它有一个明显的弱点：Full GC时是单线程的Mark-Sweep-Compact，对超大堆回收时间长，STW停顿不可控。
压测场景要的是可预测的停顿，而不是最大吞吐。G1收集器的设计目标就是在大堆内存上控制停顿时间，它通过分区回收和增量方式完成垃圾回收，能够将STW控制在目标范围内。所以我们将垃圾回收器切换到了G1，并同时在JVM参数中明确设置了最大停顿目标。
堆大小的决策也需要仔细衡量。物理机内存是16G，堆设置成多大的合适，需要看机器上还跑了什么。应用服务器上同时存在操作系统页缓存、Redis客户端缓存和网络缓冲区等内存占用。堆设12G意味着留给操作系统的内存只剩4G，页缓存不够会导致磁盘IO性能受损。最终设置了10G堆，留出6G给系统页缓存和其他开销。
JDK版本对GC调优也有影响。我们用的是JDK 8，G1在8u191之后细节经过多轮修复，升级到较新的8u版本能避开早期G1在字符串去重和RSet维护上的性能缺陷。这些版本层面的细节，直接决定了调优效果。
5.3 参数调整与复测对比
最终在JVM启动参数中落地了以下配置：
-Xms10g -Xmx10g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=8m -XX:InitiatingHeapOccupancyPercent=35 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -Xloggc:/data/logs/gc.log几个关键参数的思考过程：
-XX:MaxGCPauseMillis=200设定G1的停顿目标为200毫秒。这个值不建议设得太小，G1为了追求极短的停顿会激进地增加后台线程的扫描频率，导致CPU消耗上升。200毫秒对业务接口来说已经是可接受的上限内，再激进没有收益。
-XX:G1HeapRegionSize=8m设置了Region大小为8MB，10G堆一共会划分出1280个Region。Region大小的选择需要根据对象大小的分布来定。我们的业务对象大多在几百KB以下，8MB的Region足够分配。
-XX:InitiatingHeapOccupancyPercent=35是G1触发并发标记周期的老年代占比阈值。默认值是45，但压测场景下对象释放速率快，等堆占到45%再触发标记可能来不及，并发标记后紧接着就要做Mixed GC。调低到35让G1更早开始准备，避免老年代堆积导致退化成Full GC。
复测在完成一轮修复后进行了。两层对比数据：
| 指标 | 调优前 | 调优后 |
|---|---|---|
| Full GC次数 | 121次/20分钟 | 0次 |
| STW平均时长 | 824ms | 68ms |
| 接口P99响应时间 | 3.1秒 | 420ms |
| 接口成功率 | 98.5% | 99.98% |
调优成功后本以为可以收工，但GC日志分析还帮我们发现了另一个隐患：G1的并发标记周期在压测后半段触发频繁，后台线程扫描CPU消耗升高。进一步优化时通过调整RSet的维护参数和减少并发标记频率，把后台扫描线程的开销降了10%左右。这一步属于调优之后的效果微调，在5万QPS的目标下帮助系统腾出了更多CPU容量。
6. 常见问题与排查技巧实录
6.1 关于JMeter压测端的问题
JMeter压测机本身的瓶颈经常被忽视。单台JMeter实例在每秒处理几千个请求时，本机CPU和内存都会成为瓶颈，尤其是正则表达式提取器和JSONPath断言这些功能，CPU消耗极大。我们压测的第一版脚本，在5000并发时JMeter本机CPU跑到了95%，聚合报告里的响应时间和吞吐量已经失真。
解决方式有两种。一是去掉不必要的断言，只保留HTTP状态码和核心字段校验；二是启用JMeter分布式压测，用一台主控机和三台执行机分摊压力。这里需要注意执行机和主控机之间的时钟同步，时间不同步会导致聚合报告里的响应时间计算出现漂移。
另一个常见问题是JMeter的HTTP采样器默认不启用KeepAlive。真实用户访问是长连接，如果不开启KeepAlive，每个请求都要经历TCP三次握手和四次挥手，压测吞吐量会被明显低估。建议在HTTP请求配置里勾选使用KeepAlive，并设置合理的连接超时时间。
6.2 关于压测数据与业务逻辑验证的坑
压测数据的正确性直接影响结果。我们在第一轮压测时，测试账号的返利等级没有正确初始化，导致所有用户的佣金比例计算都走到了默认分支，返利计算接口的耗时数据比真实场景偏低。这类问题很难通过监控发现，只能靠业务口径核对。压测前建议先做一轮全链路业务验证，拿小流量把每个分支都跑通一遍再正式加压。
另一个问题是数据幂等。订单回调接口的压测会往数据库里插入大量模拟订单记录，同一笔订单被回调多次时，必须和真实逻辑一样走到幂等判断分支。如果压测数据没有做幂等控制，数据库里会出现大量重复数据，后续返利计算也会因重复入账而崩掉。压测脚本里使用固定的mock订单号，并在每轮压测前清理上一轮产生的数据。
6.3 调优后的效果与复盘心得
大促压测这整件事做完，体会最深的不是某个参数调得多好，而是“性能调优是系统性工程”这句话。最初压测领券接口，我们只以为是Java代码逻辑问题，后来顺着链条排查，发现根因是Redis热点key和数据库慢SQL的叠加效应。如果只盯着某一个小点去调，很难从根本上解决问题。
从方法论的沉淀来说，这次压测形成了三个固定动作：每次压测前先做瓶颈预估并记录到表格里，压测中按照梯度加压模型收集阶段数据，压测后针对每一个问题形成修复前后的对比记录。这套流程在同团队另一个项目上复用了一次，效果同样明显。建议做压测的团队不要只把压测当一次任务来完成，把积累的数据和方法论沉淀下来，后续每次迭代都可以快速响应。
最后分享一个实用小技巧：压测过程中实时观察GC日志比事后看汇总数据要有效得多。GC日志是连续生产的，如果看到Young GC频率在短时间内成倍上升，往往是对象分配速率异常的前兆信号，这时候可以先在线上的流量入口做一下限流挡板，防止问题在压测阶段快速扩散。这个小动作帮我们避免了好几次压测现场的被动局面。
