高并发下游 RT 抖动场景下，自适应并发限流 vs 固定 QPS 限流如何选型

背景 我负责一个聚合网关（Java 17，Netty + Reactor），核心是把多个下游（订单、库存、风控）的结果并发扇出后再聚合返回。整体 QPS 约 3000，单个下游 RT 正常 20~60ms，但风控下游 P99 会周期性飙到 800ms~2s（对方批次处理导致）。我们不想用一个很大的全局线程池硬扛，希望从"限流/并发控制"层面把对下游的冲击控制住，同时尽量不牺牲本服务的吞吐。

现象 用固定 QPS 限流（Guava RateLimiter / 令牌桶）时遇到两个矛盾： 1）平时风控 RT 正常，固定 QPS 放过去的请求都很快，但一旦风控进入慢批次，已放过去的在途请求全部堆积，导致聚合超时（本服务 P99 跟着飙）； 2）把 QPS 调低能缓解堆积，但正常时段又严重限流、白白损失吞吐。 也就是说固定速率无法感知下游"当前能消化多少"。

已尝试的排查与结果

1. 调大/调小令牌桶容量：只改变堆积的快慢，不改变堆积总量；
2. 加超时（300ms）+ 重试：重试反而加剧慢批次时的冲击，超时把 CPU 浪费在等和重发上；
3. 看了下 Reactor 的 Mono.flatMap(..., concurrency) 做并发窗口，以及 Hystrix/Sentinel 的并发数限流（concurrency limiting）思路，方向对但我没拿到量化参数和落地细节。

期望得到的答案形态 希望大家给一个可落地的对比：在"下游 RT 会抖动"的场景下，固定 QPS 限流 vs 基于并发数/在途请求数的自适应限流（concurrency limiting / AIMD）各自的取舍、适用边界、以及关键参数怎么定（在途并发上限怎么估、AIMD 的增减因子、与超时/重试如何配合）。最好能带一个伪代码或配置片段，以及一个能说明"为什么并发数比速率更适合抖动下游"的小例子。