多下游并行调用下，整链超时预算怎么切分？重试如何不突破同一个 deadline

【背景】 我负责一个支付编排服务（JDK 17 + Spring Boot 3，单机 8C16G，前置 4 实例，K8s cpu limit=4），对外 QPS 峰值约 1.5k，P99 目标 500ms。一次请求内会并行发起 4 个下游 RPC：风控（P99 80ms）、账务（P99 120ms）、库存扣减（P99 150ms）、通知（P99 60ms，可异步化但暂时同步）。每个下游我用 Resilience4j 配了独立超时 + 1 次重试（指数退避 100ms 起步）。

【现象】

1. 各下游独立超时都设 300ms、总入口超时设 800ms：平时没事，但只要其中任何一个下游抖动一次（比如库存 P99 瞬时到 400ms），触发重试后整条请求耗时直接到 300+100+400=800ms，刚好把入口 800ms 打穿，前端看到的就是超时。
2. 把各下游独立超时都压到 150ms：风控/账务没问题，但库存扣减在抖动时开始大量超时，重试反而把库存服务打挂——典型的"重试放大故障"。
3. 我试着用 Resilience4j 的 TimeLimiter + Mono.timeout 做"整链剩余预算"，但重试那一跳并没有继承 deadline：第一次调用用了 150ms 超时失败，重试时 TimeLimiter 又给了完整的 150ms，等于实际消耗 300ms+ 退避时间，预算被悄悄透支。

【已尝试】

• 把 4 个下游的超时按 P99 单独调（80/120/150/60）：抖动时依然会击穿总预算，因为预算是"每个下游各自一份"，不是"整链一份"；
• 用 CompletableFuture + allOf + 一个全局 timeout 包裹：能拿到"整链超时"，但重试逻辑还是各自为政，重试那一跳不受全局 deadline 约束；
• 把通知从同步改成异步：链路 P99 降到 380ms，但这是业务妥协，没有解决"预算切分"这个根本问题。

【期望答案形态】

1. 预算切分的模型：是"入口 deadline 一路向下传播、每个下游只拿到剩余预算"，还是"每个下游独立预算 + 入口兜底"？两种模型在并行调用下的正确性差异在哪？有没有人在生产里真的做过 deadline 传播（不是 timeout 叠加）？
2. 重试如何受同一 deadline 约束：Resilience4j / Sentinel / 自研，哪种方案能让"第 N 次重试的超时 = 剩余预算 - 已用时间 - 退避时间"？或者大家是怎么 hack 的？
3. 并行 vs 串行的预算语义：4 个并行下游，是"最慢的那个决定整链耗时"，还是"每个下游独立超时、整体取 max"？在部分失败（3 成 1 败）场景下，预算到底给谁？
4. 有没有人踩过"预算切分看着合理，但实际被连接池排队时间吃掉"的坑？deadline 应该从"发起调用"算还是从"拿到连接"算？