如何做接口压测和容量评估

做接口压测和容量评估的核心就一句话：先测出单实例在可接受延迟下的安全 QPS，再用「峰值 QPS × 冗余系数 ÷ 单实例安全 QPS」倒推所需机器数，最后留出 30% 以上的余量应对突发流量。压测不是把服务器打到挂，而是找到性能拐点并给出可执行的扩容结论。

压测的目标指标应该怎么定？

结论：压测前必须先约定四个硬指标——QPS、P99 响应时间、错误率、资源水位，缺一个都会导致结论不可用。

• QPS（每秒查询数，即接口吞吐量）：区分平均 QPS 和峰值 QPS，容量评估用峰值。
• P99 响应时间：只盯平均 RT 会被长尾掩盖，建议核心接口 P99 ≤ 200ms，非核心 ≤ 500ms。
• 错误率：压测期间要求 < 0.1%，出现超时、5xx 都算失败。
• 资源水位：CPU 稳定在 60%~70%，内存无持续增长，数据库连接池使用率 < 80%。

写清楚这四个数，压测结果才有可比性。否则跑完一次压测，开发说"挺快"，运维说"机器快满了"，等于没测。

压测工具怎么选，具体命令是什么？

结论：单接口快速摸底用 wrk，复杂业务编排用 JMeter，云原生和 CI 集成首选 k6，三者配合使用成本最低。

wrk 适合短平快的 HTTP 接口压测，一条命令即可：

wrk -t12 -c400 -d30s --latency http://127.0.0.1:8080/api/order/query

-t12 是 12 个线程，-c400 是 400 个并发连接，-d30s 压 30 秒。注意线程数不要超过压测机 CPU 核数，否则压测机自己先成为瓶颈。

JMeter 适合有登录态、参数关联、多接口串联的场景，用命令行模式跑，避免 GUI 消耗资源：

jmeter -n -t order_plan.jmx -l result.jtl -e -o report

k6 用 JS 写脚本，天然适合接进流水线：

k6 run --vus 100 --duration 5m --ramp-up 1m script.js

关键原则：压测机和被测服务不要部署在同一台机器上，且压测机 CPU 使用率应低于 70%，否则测出来的是压测机的极限，不是服务的极限。

加压方式怎么做才科学？

结论：不要一上来就压峰值，正确的做法是阶梯加压找拐点，再用拐点前的稳定值作为容量基线。

具体步骤分四步：

1. 基准压测：1 并发、10 并发各跑 1 分钟，记录 RT 基线，确认单请求链路正常。
2. 阶梯加压：每 2 分钟提升一档并发（如 50 → 100 → 200 → 400 → 800），每档记录 TPS、P99、错误率。
3. 定位拐点：当 P99 突然翻倍或错误率突破 0.1% 时，说明已越过性能拐点。取拐点前那一档作为「单实例安全 QPS」。
4. 稳定性压测：以安全 QPS 的 80% 持续压 1~2 小时，观察内存是否泄漏、连接池是否耗尽、GC 频率是否上升。

流量模型也要贴近真实：按线上日志统计的接口比例构造混合场景，而不是只压一个读接口。经验值上，读写比 9:1 和 1:1 的压测结果可能差 3 倍。

容量评估的公式和冗余系数怎么定？

结论：机器数 = 峰值 QPS × 冗余系数 ÷ 单实例安全 QPS，冗余系数生产环境建议取 1.5~2.0。

举个完整例子：某接口线上峰值 QPS 为 3000，压测得出单实例安全 QPS 为 800，取冗余系数 1.5，则所需实例数 = 3000 × 1.5 ÷ 800 ≈ 5.6，向上取整为 6 台。

冗余系数的作用是覆盖三件事：流量突增、单机故障、发布期间的滚动重启。系数取 1.0 意味着任何一台机器挂掉都会雪崩，这是最常见的容量事故来源。

还要注意木桶效应：接口的容量上限往往由最慢的依赖决定。压测时必须同时监控数据库 CPU、慢 SQL 数量、Redis 命中率、下游 RPC 超时率。如果压测中数据库 CPU 先到 90%，那扩充应用实例数毫无意义，瓶颈在 DB 层，需要加索引、加缓存或做分库分表。

压测中容易踩的坑有哪些？

结论：压测数据失真主要来自缓存穿透设置、数据倾斜和依赖未打桩三类问题。

• 缓存：压测前必须确认是冷缓存还是热缓存，两者 QPS 可能相差 10 倍以上。建议分别测一轮，按冷缓存结果做容量规划更保守。
• 数据倾斜：压测参数如果每次都查同一条记录，数据库缓存会让结果虚高。参数要随机化，覆盖至少 10 万条不同 ID。
• 外部依赖：短信、支付、第三方 API 必须在压测环境打桩（Mock），否则会真的发出短信，也可能被对方限流导致误判。
• 连接池：应用侧 HTTP 连接池、数据库连接池的最大连接数要显式配置，默认值常常是 10 或 20，会先于机器 CPU 成为瓶颈。

上线后怎么验证容量结论？

结论：上线后要用真实流量做一次验证，把压测结论和监控数据对齐，否则只是纸面数字。

推荐两条路径：一是观察大促或业务高峰时的真实峰值 QPS 与 P99，对比压测推演的容量线；二是做全链路压测，用影子表或流量标染的方式在真实生产环境施压，但必须做好数据隔离，避免污染线上数据。

容量评估不是一次性动作。业务迭代、SQL 变更、依赖升级都会改变单实例安全 QPS，建议每个大版本发布后重跑一次基准压测，把容量基线纳入发布检查清单。

总结一下：先定 QPS、P99、错误率、资源水位四个指标，用 wrk/JMeter/k6 阶梯加压找到性能拐点，取拐点前的值作为单实例安全 QPS，再乘以 1.5~2.0 的冗余系数推算机器数，最后同步排查数据库、缓存、连接池这些木桶短板。做到这几步，容量评估就从"拍脑袋"变成了有公式、有数据、可复现的工程结论。