电商大促前，服务器压力测试和巡检的核心是提前暴露系统瓶颈并完成容量规划，确保大促当天系统稳定不崩。
大促前服务器压力测试怎么做才能不踩坑
大促前的压力测试不是简单拿工具打个流量就完事,它是一套从业务场景梳理到容量规划落地的完整流程，这里有一套经过多年大促验证的实操路径。
压测前的准备工作：先摸清家底
- 梳理核心链路：列出用户访问量最大的页面和接口，如首页、搜索、商品详情、下单、支付回调。
- 盘点机器资源：统计所有应用服务器、数据库、缓存、消息队列的配置和数量，你可以用脚本快速收集CPU核数和内存大小，例如在Linux下执行
lscpu和free -h。 - 确认压测环境：尽量使用与生产环境配置一致的独立压测集群，如果条件有限，至少要做到应用规格一致、网络拓扑一致。
压测场景设计：别只测一个接口
- 容量测试：确认当前集群能支撑的最大并发数，找出拐点，以商品详情页为例，观察TPS从1000升到2000时，响应时间是否从50ms暴涨到500ms。
- 稳定性测试：模拟大促期间的持续流量，比如以峰值流量的80%持续跑30分钟到1小时，重点观察内存泄漏和Full GC频率。
- 异常演练：主动杀掉一个应用节点或模拟数据库主从切换，验证系统的高可用策略是否生效。
压测工具选型：JMeter、wrk与k6怎么选
| 工具 | 适用场景 | 资源消耗 | 学习成本 |
|---|---|---|---|
| JMeter | 复杂业务流，多接口关联 | 较高，单机压力有限 | 中等 |
| wrk | 简单接口的极限吞吐测试 | 极低，单机可压出高并发 | 低 |
| k6 | 脚本化压测，CI/CD集成 | 较低 | 中等 |
- JMeter 适合模拟用户从登录到下单的完整路径，可以在脚本里用JSON提取器获取Token并传递给下一个请求。
- wrk 写一个
wrk -t12 -c400 -d30s http://example.com/api命令，就能快速压出一个接口的QPS上限。 - k6 用JavaScript编写场景，适合在流水线里自动触发。
大促前服务器巡检必查的五个关键维度
压测发现问题后,巡检用来排查隐患，以下五个维度是大促前48小时必须完成的体检项。
CPU与内存：系统是否“虚胖”
- 用
top命令查看%Cpu(s)的si值，如果这个值持续偏高，说明CPU在频繁处理软中断，通常意味着网卡队列已满或锁竞争激烈。 - 检查
free -m的available字段，这个值比free更能反映真实可用内存。available低于总内存的20%，就需要排查是否有进程在持续申请堆外内存。
磁盘I/O与空间：慢日志与满盘是两大杀手
- 执行
iostat -x 1，重点看%util，当这个值超过80%，磁盘基本处于饱和状态，数据库查询会明显变慢。 - 使用
df -h检查磁盘使用率，务必给日志分区预留至少30% 的余量，很多系统崩溃不是内存不够，而是/var/log目录被访问日志写满。
数据库与缓存：核心枢纽不能掉链子
- MySQL：查看
show global status like 'Threads_running'，大促前这个值如果长期超过50，说明连接池配置偏大或存在慢SQL，再检查slow_query_log，找出执行时间超过1秒的查询，提前加索引或改写。 - Redis：用
redis-cli info memory查看used_memory与maxmemory的比例，当使用率超过80%，考虑淘汰策略是否合理，并检查是否存在大Key，大于 10KB 的String或包含 5000个 以上元素的Hash都应该被拆分。 - 缓存穿透：模拟查询一个不存在的商品ID，如果QPS瞬间冲高且数据库压力激增，说明缓存空值策略没生效。
网络与防火墙：带宽跑满等于服务不可用
- 用
iftop观察实时带宽，对比与运营商带宽上限的差距，大促时流量突增，带宽跑满会让所有请求超时，表现出的现象和宕机一模一样。 - 检查负载均衡的队列长度,
Listen-Overflows计数持续增长，说明后端节点响应太慢，需要扩容。
容量规划：到底要加多少台机器
业内专家指出,容量规划不是拍脑袋，而是基于压测结果和业务预估的科学计算。
从压测结果推导扩容方案
- 假设当前集群有 10台 应用服务器，压测得出单机支撑 1000 QPS，总容量就是 10000 QPS。
- 大促预估峰值流量为 50000 QPS，那么至少需要 50台 服务器，建议在此基础上再预留 30% 的Buffer，即最终准备 65台 左右的资源。
- 数据库在压测时达到 5000 QPS 时CPU使用率已到 70%，如果预估峰值数据库QPS为 15000，则需要考虑读写分离或分库分表。
弹性伸缩策略：留一手后招
- 在云环境里,提前配置好定时弹性伸缩规则，例如从大促前2小时开始逐步扩容，避免流量瞬间涌入时扩容来不及。
- 提前准备好备用镜像，确保新扩容的机器拉起来就是最新的应用版本和配置，不用再手工执行部署脚本。
大促当天的实时监控与应急预案
巡检和压测做完了,还有最后一道防线：值班手册。
监控大盘要盯什么
- 应用层：接口成功率低于 9% 时触发告警；响应时间P99超过 500ms 时需要立即查看。
- 系统层：CPU使用率持续 80% 以上超过5分钟；内存使用率超过 90%。
- 业务层：核心指标如订单创建速率、支付成功率出现断崖式下跌，这一般是系统出问题的前兆。
应急预案清单
- 数据库连接打满：执行
show processlist，批量Kill掉长时间运行的SELECT查询，再考虑重启连接池。 - 缓存雪崩：开启Redis的
appendonly yes持久化或使用本地Ehcache兜底，同时加分布式锁防击穿。 - 应用假死：如果Java应用出现频繁Full GC，使用
jmap -dump导出堆快照分析，先重启节点保命，后续再定位根因。 - 限流降级：在网关层面提前配置Sentinel或Hystrix规则，当流量超过阈值时，直接返回兜底页面或降级文案。
大促前压测与巡检的核心逻辑是用确定性对抗不确定性，把大促当天的不可控因素提前消化在预案里，所有操作都应以真实业务场景为基准，以数据为依据，稳妥度过流量洪峰。
电商大促服务器压测与巡检常见问题解答
压测到什么指标算安全，可以放心迎接流量高峰？
重点看两组数,第一组是接口的P99响应时间，在预估峰值流量下，P99必须低于业务方给出的容忍线，多数电商场景要求 500ms以内，第二组是系统资源水位，CPU使用率在压测峰值时最好低于 70%，内存使用率低于 80%，磁盘I/O的 %util 低于 60%，满足这两个条件，再留出部分余量，基本可以认为容量规划到位。
大促前巡检时发现数据库有慢SQL，时间来不及怎么快速处理？
最有效的手段是加索引，用 explain 查看执行计划，如果发现是全表扫描，针对WHERE条件中的字段创建联合索引，往往能立刻将查询时间从秒级降到毫秒级，如果SQL本身逻辑复杂，可以考虑在应用层加Redis缓存将查询结果暂存，也能有效缓解数据库压力。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774737.html
