阿里云 PTS 压测实践：千里达票务系统节前容量规划
每逢五一、国庆，千里达票务系统都要经历一次"压力大考"。与其开园当天提心吊胆，不如节前用阿里云 PTS（性能测试服务）主动压一遍。本文分享我们用 PTS 做容量规划的完整流程与踩坑经验。
一、为什么要做节前压测
- 业务量可预测：历年节假日峰值 QPS 有数据可循，增量可预估；
- 扩容要依据：加几台 ECS、升不升 RDS 规格，不能拍脑袋，要用压测数据说话；
- 风险前置：把超卖、卡顿、宕机的风险在节前暴露并修复。
二、方案设计
2.1 压测场景设计
| 场景 | 施压模型 | 目标 |
|---|---|---|
| 开园抢票 | 3000 并发，持续 30 分钟 | 验证下单链路极限 |
| 余票查询 | 5000 并发 | 验证读链路与缓存命中 |
| 混合场景 | 按真实比例混压 | 贴近真实流量结构 |
2.2 压测环境
- 首选生产环境隔离压测（PTS 支持压测流量染色，不污染真实数据）；
- 压测前对数据表做备份，压测产生的脏数据压测后清理。
三、关键实现
3.1 压测报告核心指标解读
- TPS：系统每秒处理事务数，与业务目标对比；
- RT（P99/P95）：游客真实体验，目标 P99 < 300ms；
- 错误率：压测下暴露的 4xx/5xx，逐项排查；
- 资源水位：压测同时观察 ECS CPU、RDS 连接数、Redis 命中率。
3.2 扩容决策模板
若 P99 超标且 ECS CPU < 60% → 排查应用瓶颈（锁、慢SQL、GC）
若 ECS CPU > 80% → 横向扩容 ECS（+SLB 自动接入）
若 RDS 连接数 > 70% → 开启只读实例分担 or 升配
四、踩坑复盘
- 压测污染生产数据：首次直接在生产的订单表跑压测，产生大量垃圾订单。解决：压测流量染色 + 独立表 + 压测后清理脚本；
- 参数关联缺失：所有并发用户用同一手机号下单，被业务幂等拦截，压测结果失真。解决：压测参数化，每用户独立手机号/证件号；
- 只看平均值：平均延迟 80ms 看似健康，P99 实际已到 1 秒。解决：重点看 P95/P99 与长尾；
- 压测即扩容的错误逻辑：压测通过就以为万无一失，忽略真实流量比压测更"野"。解决：预留 30% 冗余，并保留节中动态扩容预案。
五、效果与总结
通过 PTS 节前压测，千里达票务系统在近年国庆高峰稳定支撑单景区 3000+ QPS 峰值，未发生下单链路宕机。容量规划不再是"赌运气"，而是有数据支撑的工程决策。对任何有波峰业务的系统，PTS 都是成本最低的"事前保险"。
