HikariCP 连接池容量到底怎么定量算：下游延迟分布已知时，如何避免打满又不浪费

背景 我在给一个订单履约服务做容量评审，单 Pod 8C16G，业务侧 600 QPS 稳态，下游三类：MySQL 8（p99=12ms）、Redis 7（p99=2ms）、第三方 HTTP（p99=380ms，超时 800ms）。目前 HikariCP maxSize=50、Redis 池=100、HTTP 客户端 pool=200。上个月一次下游 DB 抖动（p99 从 12ms 飙到 450ms，持续 40s），直接把我们整个服务拖到 P99 6s+，连接池打满后所有非 DB 路径也全部阻塞，最终触发级联故障。

现象 事后复盘发现三件事都很反直觉：

1. 池子 50 看着"够"（理论 600×0.012=7.2），但下游一抖直接打满，说明稳态公式在抖动场景下完全失效；
2. 三个下游共用一个线程池（Tomcat 200），DB 慢请求占住线程后，Redis/HTTP 路径也跟着排队，等于一个慢下游拖死了全部；
3. 团队第一反应是"把池子调大"，有人主张调到 500，但下游 DB 侧 max_connections 才 800，10 个 Pod 一抖就集体把 DB 压垮——这就是社区里"池子从 200 调到 2000 反而雪崩"那个帖子的同款坑。

已尝试的排查

• 用 Little's Law 按稳态算：600 QPS × 12ms = 7.2 连接，池 50 富余 7 倍；
• 但按抖动场景算：600 × 450ms = 270 连接，池 50 直接不够 → 说明容量必须按 P99 抖动算而不是稳态；
• 试了把 HTTP 客户端 timeout 从 800ms 收紧到 300ms，P99 抖动幅度确实降了，但业务方投诉"误杀率"上升 3%（第三方本身就是 380ms p99）；
• 试了三个下游分线程池隔离（Tomcat 拆 3 个），隔离效果明显但线程总数从 200 涨到 400，内存和 context switch 代价需要再算一遍。

期望得到的答案形态 希望有人能给出一个可复现的定量公式或决策树，覆盖：

1. 池子大小 = f(QPS, 下游 P99 延迟, 抖动放大系数, 实例数, 下游侧 max_connections) 的具体推导；
2. 抖动放大系数怎么取值（我猜 5~10x，但没数据支撑）；
3. 多下游场景下，池隔离 vs 共享线程池的取舍条件（什么延迟分布下必须隔离）；
4. 有没有人踩过"池子调大反而更糟"的具体案例，根因是什么。

欢迎带真实生产数据来打我的脸。