串行链路 deadline 逐级传递后，末跳剩余额度掉到 30~50ms 低于自身 P50：该不该发起、阈值怎么定、降级判据有没有可复现做法？

背景 Java 17 + Spring Boot，订单履约链路是 4 跳纯串行：网关(800ms SLO) → 订单服务 → 库存服务 → 风控服务 → 结算服务（最后一跳落 MySQL，一条事务内含 3 条 DML + 1 条查询，P50 约 45ms、P99 约 90ms）。deadline 已经在链路里逐级传递：每跳用 max(1ms, 0.6 × remaining) 给下游算单跳超时，自己留 40% 做本地计算和序列化。前 3 跳 P99 都在 80ms 以内，平时没问题。

现象 上周风控服务一次 GC 抖到 400ms（持续约 6s），期间大量请求到达结算服务时 remaining 只剩 30~50ms——低于结算服务自己的 P50（45ms）。结果是：

1. 这些请求发起 MySQL 后几乎必然超时，事务回滚，用户看到「支付失败」，客诉 12 单；
2. 更糟的是这些超时请求把 MySQL 的活跃连接顶上去（HikariCP active 从 12 涨到 48），拖慢了后面剩余预算充足的新请求，形成一小段二次恶化；
3. 事后看数据：remaining < 50ms 的请求成功率只有 18%，remaining > 150ms 的成功率 99.6%——中间地带 50~150ms 成功率 60%~90%，波动很大。

已尝试的排查与结果

• 试过把 0.6 系数调成 0.7（给下游多留），结果前 3 跳自己的本地计算偶尔超时，总超时率反而升了 0.3%；
• 试过在结算服务入口加「remaining < 100ms 直接快速失败」，但 100ms 这个数是拍脑袋定的：调成 80ms 成功率从 18% 变成 31%（因为部分 80~100ms 的请求其实能成），调成 120ms 又误杀了本该成功的请求——没有一套从数据里反推阈值的可复现方法；
• 也考虑过「remaining 不足时降级为只写流水、跳过风控结果落库」，但不确定降级后的一致性边界怎么保证（补偿任务扫哪个时间窗、对账口径怎么改）。

期望得到的答案形态

1. 一个从线上 P50/P99 分布反推「最小可执行预算阈值」的可复现方法（比如：阈值 = 本跳 P50 + 本地计算 P99 + 安全系数？还是看成功率曲线的拐点？）——最好有具体的取数 SQL/指标口径；
2. 阈值命中后的动作选择判据：快速失败 vs 降级执行 vs 照常尝试，什么场景选哪个，降级的一致性边界怎么划；
3. 有没有人在串行链路里踩过「末跳预算饥饿」这个坑、最后用什么方案收的尾。

参考：站内已有 deadline 逐层传递的讨论（id=1013，各层留余量导致总超时超 SLA）和超时预算切分问题（id=1501），但都没深入到「剩余额度低于自身 P50 时怎么办」这一层，所以单独问这一卡点。