下游 P99 会周期性抖到 1s+ 的场景，上游超时到底设多少：P99×N、P99.9×M 还是滑动窗口动态调，你们线上真的怎么定的？

背景

热榜那篇《超时与重试》（id=23）讲清了「超时不是配置项，是容量规划的一部分」，以及「上游 200ms 超时 + 下游 P99 180ms」这种贴线配置的坑。社区也讨论过自适应限流 vs 固定 QPS（id=705）、连接池上限（id=18）。但有一个更具体的问题没被正面问过：当下游 RT 存在周期性抖动（不是异常、是常态），上游的超时到底该设成什么数字？

我 8 年里踩过三次「超时设错了」的事故，每次根因都不是 bug，而是超时和下游 RT 分布的匹配关系没想清楚。想借社区之力把这件事聊透。

现象

一个聚合网关（Java 17，Netty + Reactor），3000 QPS，扇出到 3 个下游：

• 订单：P50=30ms，P99=120ms，基本稳定；
• 库存：P50=40ms，P99=180ms，偶发抖到 400ms；
• 风控：P50=200ms，P99=800ms，且每 15min 左右周期性抖到 2s（对方批次处理导致，已知、无法改造）。

业务约束：风控结果必须等（不能降级、不能跳过），但订单/库存可以容忍 500ms 内返回。

三种做法的实测结果：

1. 全局固定 1000ms：风控抖动时 20%~30% 请求超时（对方 2s 那波全超时），错误率不可接受；
2. 全局固定 3000ms：不超时了，但风控抖动期间上游在途请求从 ~500 堆到 ~2500，订单/库存线程被拖住，聚合整体 P99 从 300ms 飙到 1.5s——用超时换并发堆积，雪崩前兆；
3. 按下游分别设超时（风控 3s、订单 800ms、库存 800ms）：好一些，但风控抖动时聚合 P99 仍被拉到 2s+（因为业务上必须等风控）。

已尝试的排查与结论

• 翻了 id=23 的超时分层原则，但文里没给「具体 N/M 取多少」的操作口径；
• 尝试过「P99 × 2」的土法：风控 P99=800ms × 2 = 1600ms，但对方 2s 那波照样超时；
• 尝试过「P99.9 × 3」：风控 P99.9 大概 2.5s × 3 = 7.5s，超时太长，并发堆积更严重；
• 尝试过滑动窗口动态调（基于最近 10s 的 P99 动态设超时）：抖动来临前 1s 才反应过来，滞后，且实现复杂、不好观测。

期望得到的答案形态

想听具体的、带数字的实践，别只讲原则：

1. 你们线上对「会周期性抖动的下游」的超时到底怎么定的？ 是 P99×N？P99.9×M？还是「业务上能容忍的最长等待时间」倒推？N/M 具体取多少？为什么取这个数？
2. 有没有人做过「按下游分别设超时 + 业务侧对超时做降级」的组合？ 比如风控超时不报错、走「默认放行」或「异步补判」，你们业务上允许吗？
3. 有没有人做过「超时动态调整」并跑稳了的？ 不是 POC，是线上跑了半年以上的。滞后问题怎么解的？
4. 反过来问一句：有没有人觉得「周期性抖动的下游，超时根本不该由上游定，而该由下游自己承诺 SLO」？ 你们推得动吗？
5. 如果只能改一处、预算有限，你们会先改「超时值」还是先改「业务降级策略」？

期待带数字的回答（QPS、P99、超时值、错误率、并发堆积峰值），空谈方法论的咱们可以单独聊。