高并发系统里 P99 与吞吐到底先保谁：你的 SLO 是怎么定出来的

背景 社区里最近热榜上全是 P99 抖动、超时重试、Kafka 事务卡顿这类"单点排查"的帖子，写得都很扎实。但我作为带团队的人，更纠结的是另一个更上游的问题：当 P99 和吞吐真的冲突时，你的系统到底先保谁？

举几个我们组真实面对过的场景，大家可以对号入座：

1. 订单下单链路：大促压测时，QPS 从 8k 压到 1.5w，P50 从 30ms 涨到 80ms，P99 从 120ms 涨到 800ms。要不要限流把 QPS 砍回 1w 换 P99 < 200ms？
2. 对账批处理：跑批窗口固定 2 小时，全量 2 亿行。是"宁可跑不完明天补跑"（保 P99 单条耗时稳定），还是"必须 2 小时内跑完"（保吞吐，容忍单条 P99 抖动）？
3. 支付回调：下游渠道偶尔 3s 才回包，我们是同步等（P99 难看但链路简单），还是丢进 MQ 异步（吞吐上去了但状态查询变难）？

常见的几种分歧

• 一派说"P99 是用户感知，必须保；吞吐靠扩容解决"——逻辑很正，但扩容有成本，且 P99 对长尾极敏感，一次 GC 就爆。
• 一派说"吞吐是业务价值，P99 只是指标；能扛住峰值 QPS 才是真本事"——但 P99 一抖，超时重试风暴反而把系统打挂，见过太多次。
• 还有一派"看场景"：读多写少保 P99，批处理保吞吐，资金链路两个都保但用异步换——这个说法最对，但最没法直接落地。

我的倾向与理由 我倾向"先保 P99，用 P99 预算倒推吞吐上限"，理由有三：

1. SLO 语义上，P99 是对外承诺，吞吐是内部能力。对外承诺破了就是故障，内部能力没到只是不达标。
2. P99 稳定，超时重试才可控。重试是 P99 抖动的放大器，P99 不稳 → 重试风暴 → 雪崩，这条链路比"吞吐不够"危险得多。
3. 吞吐可以横向扩、可以限流降级，P99 长尾却往往卡在单点（GC、锁、慢查询），事后补很难。

但这不是无条件的：纯批处理、离线对账、日志投递这类"没有实时用户感知"的链路，我会反过来——保吞吐，P99 只作为观测指标。

想听大家

• 你的 SLO 是怎么定出来的？是业务方拍脑袋、还是从用户行为数据反推？
• 有没有"P99 保住了但吞吐没扛住，最后背锅的是 P99 策略"的真实案例？
• 对"资金链路"这种两个都要保的场景，你们具体怎么拆？同步 + 异步的边界划在哪？

欢迎贴你团队的真实配置和取舍，越具体越好，空谈"看场景"的我们不聊 😄