一、项目背景
某跨境代购平台在大促期间频繁出现页面加载慢、下单超时、支付失败 等问题，日均订单量峰值达 5 万单，系统稳定性严重影响转化与口碑。为保障黑五、年终大促等高峰场景稳定运行，开展全链路压力测试与性能优化，目标是支撑1000 并发用户、订单创建 TPS≥200、核心接口响应时间 < 500ms、成功率≥99.9%。
二、测试环境与工具
测试环境
- 服务器：4 核 8G×3 应用节点、8 核 16G 主库 + 从库、Redis 集群
- 网络：专线 + CDN，模拟境外用户访问链路
- 数据：10 万 + 商品、20 万用户、50 万历史订单
测试工具
- 压测工具：JMeter、k6
- 监控工具：Prometheus+Grafana、SkyWalking
- 数据库分析：MySQL Slow Log、Explain 分析
三、压测场景设计
覆盖代购核心业务流程，按流量比例建模：
- 首页 / 商品列表（40%）：分页、筛选、搜索
- 商品详情（25%）：详情查询、库存校验
- 购物车（15%）：增删改查、价格计算
- 创建订单（10%）：地址、库存、优惠券、运费计算
- 支付回调（5%）：第三方支付结果同步
- 极限压力：逐步加压至系统崩溃，定位拐点
四、关键性能指标
表格
| 指标 | 目标值 | 压测初始值 | 优化后值 |
|---|---|---|---|
| 并发用户数 | 1000 | 1000 | 1500 |
| 订单创建 TPS | ≥200 | 86 | 242 |
| 平均响应时间 | <500ms | 1800ms | 320ms |
| 请求成功率 | ≥99.9% | 92.3% | 99.95% |
| 数据库 CPU | <70% | 95% | 62% |
| Redis 命中率 | ≥90% | 72% | 94% |
五、瓶颈定位与分析
1. 数据库瓶颈
- 多表联查、未建索引导致慢查询频发，订单创建耗时超 1.5s
- 高并发下行锁竞争，库存与订单表写入阻塞
- 连接池设置过小，大量请求等待连接
2. 应用服务瓶颈
- Tomcat 线程数不足，请求排队严重
- 未做异步处理，支付、物流接口同步阻塞
- 日志打印过量，IO 与 CPU 占用高
3. 缓存与架构瓶颈
- 热点商品未缓存，频繁查库
- 缺少读写分离，单库承担读写压力
- 境外用户访问静态资源延迟高
六、优化方案
数据库优化
- 为订单、商品、用户表添加联合索引，优化分页与联查 SQL
- 开启读写分离，查询走从库、写入走主库
- 调大连接池，启用事务超时控制，减少锁等待
- 定期清理历史数据，降低单表数据量
应用服务优化
- 调优 Tomcat 线程池、JVM 参数，提升并发处理能力
- 支付、物流、短信改为异步化，解耦阻塞流程
- 精简日志级别，关闭调试日志，降低 IO 开销
- 核心接口做限流与降级，保障核心链路可用
缓存与架构优化
- Redis 缓存热点商品、首页数据、购物车，设置合理过期时间
- 静态资源接入CDN，降低境外用户加载延迟
- 服务水平扩容，接入负载均衡，支持弹性伸缩
- 增加多级缓存，减少数据库穿透
七、压测结果与收益
优化后系统完全满足大促指标：
- 1500 并发下运行稳定，无宕机、无大量超时
- 订单创建 TPS 达242 ，响应时间降至320ms
- 请求成功率99.95%，数据库 CPU 控制在 62% 以内
- 大促期间零宕机，订单转化率提升 12%，客诉下降 85%
八、总结与建议
代购系统属于高并发、强一致性、跨地域场景，性能瓶颈多集中在数据库、缓存与异步设计。建议：
- 大促前全链路压测常态化，提前发现瓶颈
- 核心链路读写分离 + 多级缓存 + 异步化，提升吞吐
- 建立实时监控告警，快速定位线上问题
- 按流量弹性扩容，避免资源浪费或不足