10 - 压测与监控
前面反复强调「先测量、再优化」。这一章讲清楚：怎么测（压测）、看什么（监控指标）。没有数据，优化就是盲人摸象。
一句话先记住：压测告诉你「上限在哪、瓶颈在哪」，监控告诉你「线上此刻健不健康」。
10.1 压测：主动找出系统的极限
压测（压力测试）就是用工具模拟大量请求打你的接口，观察它在什么流量下开始变慢、在什么流量下崩溃。
压测能回答的问题
· 我这个接口最多能扛多少 QPS？
· 到多少并发时响应时间开始飙升？
· 瓶颈是 CPU、内存，还是数据库？
· 加了缓存/改了异步后，到底有没有变好？（对比验证）常用压测工具
| 工具 | 特点 | 适合 |
|---|---|---|
| wrk | 轻量、高性能、命令行 | 快速压单个接口 |
| Locust | Python 写脚本、有 Web 界面 | 模拟复杂用户行为，和 Python 栈契合 |
| ab (ApacheBench) | 最简单，老牌 | 最快速的冒烟测试 |
| k6 / JMeter | 功能全面 | 复杂场景、团队协作 |
压测的正确姿势
1. 从小流量开始，逐步加压（阶梯式）
2. 观察：QPS 到多少后，响应时间开始明显上升？
3. 找到「拐点」——那就是当前系统的容量上限
4. 定位拐点时的瓶颈（看监控：CPU？DB？连接池？）
5. 优化 → 再压一遍 → 对比是否提升注意：压测环境要尽量接近生产（数据量、配置），否则数据没参考价值。别拿空数据库压出来的 QPS 当真。
10.2 监控：盯住线上健康状况
压测是「上线前主动测」，监控是「上线后持续盯」。要监控的指标分几层：
应用层指标（黄金四指标 / RED）
· QPS / 吞吐量 —— 每秒处理多少请求
· 响应时间（RT） —— 尤其看 P95 / P99（见下文）
· 错误率 —— 5xx、超时占比
· 并发数 / 排队情况 —— 有没有请求在排队资源层指标（USE）
· CPU 使用率
· 内存使用率
· 磁盘 IO / 网络 IO
· 连接数（数据库连接池占用、TCP 连接数）数据库层指标
· 慢查询数量
· 活跃连接数 / 连接池是否打满
· 主从复制延迟（读写分离时）
· 缓存命中率（Redis）10.3 一个关键概念：P95 / P99
不要只看「平均响应时间」，它会骗你。 要看分位数（Percentile）：
P95 = 95% 的请求都比这个值快（只有 5% 比它慢）
P99 = 99% 的请求都比这个值快（只有 1% 比它慢）
举例：1000 个请求
平均 RT = 50ms ← 看起来很好
但 P99 = 2000ms ← 有 10 个请求慢到 2 秒！
平均值被大量快请求「拉低」，掩盖了少数极慢的请求。
而那些慢请求，往往就是用户投诉的来源。经验：优化和 SLA（服务等级目标）通常盯 P95 / P99，而不是平均值。因为「大部分人的体验」比「平均体验」更真实。
10.4 常见监控工具组合
| 用途 | 常见工具 |
|---|---|
| 指标采集 + 可视化 | Prometheus + Grafana |
| 日志收集分析 | ELK（Elasticsearch + Logstash + Kibana）/ Loki |
| 链路追踪 | Jaeger / SkyWalking（看一个请求在各服务耗时） |
| 错误告警 | Sentry / 告警规则（钉钉、企业微信通知） |
这些是「运维/可观测性」的范畴，了解它们能回答什么问题即可，具体搭建可以后面单独学。
10.5 优化闭环
把压测和监控串起来，就是完整的优化闭环：
┌─────────────────────────────────────┐
│ │
▼ │
[压测] → [看监控找瓶颈] → [针对性优化] → [再压测验证]
│ │
└───────────────────────────────────────┘
瓶颈会转移，循环直到满足目标本章小结
| 你要记住 | 要点 |
|---|---|
| 压测 | 主动找系统上限和瓶颈，工具：wrk / Locust |
| 压测姿势 | 逐步加压找拐点，环境要接近生产 |
| 监控分层 | 应用层（QPS/RT/错误率）+ 资源层（CPU/内存/连接）+ DB 层 |
| P95/P99 | 别只看平均值，分位数才反映真实体验 |
| 优化闭环 | 压测 → 找瓶颈 → 优化 → 再压测 |
下一章预告：最后一章，把整个系列的所有手段汇成一张「高并发优化决策树」，让你遇到问题时按图索骥。
上一章 ← 09 - 一个高并发接口的优化实录 ｜ 下一章 → 11 - 总结：高并发优化决策树