【背景】 做了 15 年高并发系统，我处理过 3 次"P99 抖到 800ms"的线上工单。团队的第一反应惊人地一致：加机器、扩连接池、上缓存。事后复盘 2 次发现——根因根本不是容量不够：一次是订单聚合接口里一条 N+1 查询把连接池占满（active 占比 98%，pending 线程 200+），另一次是一个 32 字节的锁粒度太粗，串行化了 3 个本可并行的写路径。加 3 倍机器，P99 纹丝不动。
但我也见过反例：一个读接口 QPS 从 2000 涨到 8000，代码逻辑没有任何变化，纯粹是流量上来了，砍复杂度砍到吐口水也没用，老老实实扩容 + 加 CDN 才是正解。
所以我想把这个问题正面拉出来：当 P99 抖动反复出现、团队要动手时，第一刀到底切哪里？
【三种常见做法，各自都有道理】
- 派 A：先加容量。 横向扩容、加缓存、扩连接池、加副本。理由是"业务等不起，先扛住再说，根因慢慢查"。这个策略在流量突增（大促、热点事件）场景下确实最快见效，风险是：如果根因是复杂度，容量加到第 5 台机器时你会发现 P99 还在抖，而成本已经翻 5 倍。
- 派 B：先降复杂度。 砍 N+1 查询、拆粗锁、合并 RPC、砍掉不必要的同步等待。理由是"复杂度是治本，容量是治标，砍掉一条慢查询省下的连接数比加 3 台机器还多"。风险是：如果根因纯粹是流量增长，你在代码里改来改去，业务窗口期已经过了。
- 派 C：先观测。 把 active/pending 连接占比、慢查询 Top-N、GC 停顿、锁等待时间打全，用数据区分"是容量不够还是代码太烂"，再决定动哪把刀。理由是"没有数据的扩容就是拍脑袋，没有数据的优化就是盲人摸象"。风险是：打 metrics 本身也要时间，如果 P99 正在恶化、每分钟都在丢单，"先观测"这个动作本身可能就是最贵的。
【我的倾向】 我站派 C，但有一个硬性前提：观测的粒度必须够到"能区分容量问题 vs 复杂度问题"的分辨率。
具体怎么做（以连接池场景为例）：
- 先拉
active / max占比和pending线程数的 5 分钟滑动窗口——如果 active 占比持续 > 80% 且 pending > 0，大概率是容量问题（连接不够用），这时候加副本或扩池比砍代码快。 - 如果 active 占比不高（< 50%）但 P99 照样抖，大概率是复杂度问题——某条慢查询把单连接占住了，其他请求在等锁或等 IO。这时候砍那条慢查询，比加 10 台机器都管用。
- 如果是 GC 停顿导致的抖动（
gc.pause> 100ms 且频率 > 1 次/10s），那既不是容量也不是查询复杂度，是内存模型的问题，得动堆或换 GC。
这三步判断的总耗时，在我经验里不超过 20 分钟（前提是 metrics 已经打好了）。如果 metrics 没打好，那第一步不是"先加容量"也不是"先砍代码"，而是花 1 小时把这几个指标补上——这笔账算下来远比"先扩容 3 台机器然后发现没用再回头查根因"便宜。
【想听大家】
- 你团队在 P99 抖动时的默认第一动作是什么？是"先扩容"还是"先查慢查询"还是"先看 metrics"？你的判断依据是什么——QPS 趋势、慢查询日志、GC 日志、还是"凭经验"？
- 有没有"先降复杂度"但事后发现"其实容量才是根因"的反例？或者反过来？
- 派 C（先观测）的"20 分钟判断"在你们团队现实吗？还是说 metrics 根本就没打好，"先观测"这句话本身就是空话？
- 如果 P99 正在恶化、每分钟都在丢单，你还会坚持"先观测再动手"吗？还是直接"先扩容止血、再回头查根因"？
我个人的答案是：如果丢单速率 > 业务容忍阈值（比如 > 0.1% 请求失败），我会先扩容止血，同时开一个"根因追踪"的并行线程；如果丢单速率 < 阈值，我会坚持先观测 20 分钟再动手。但这个"阈值"到底怎么定，我还没有一个可复用的公式——想听听大家怎么定。
0赞
0收藏
0楼层