HikariCP maxLifetime 比 LB 空闲超时还长：首请求失败尖峰怎么压到 P99 之外？keepaliveTime 到底敢不敢开、开多大？

【背景】 一个订单服务，Spring Boot 3.2 + JDK 17 + HikariCP 5.1，K8s 4 副本（4C/8G），入口稳态 800 QPS、峰值 1500。链路：K8s Service → 内网 LB（SLB/ALB，TCP 空闲超时 350s）→ MySQL 8.0.35（wait_timeout=28800s）。HikariCP 默认 maximumPoolSize=10、minIdle=10、maxLifetime=30min（默认 1800s > 350s）、keepaliveTime 未显式设置（HikariCP 5.x 默认 300s，但只作用于 minIdle 内的空闲连接，且是「发 keepalive 探测」而非「强制重建」）。

【现象】 每天 1–2 次 P99 尖峰（单次 200–400ms，持续 1–3s），特征很典型：

1. 尖峰前 30–60s 没有任何 GC、慢日志、锁等待异常；
2. 尖峰时刻日志里出现 SQLTransientConnectionException: Connection is not available, request timed out after 30000ms 或 CommunicationsException: Communications link failure，同一时刻同一 Pod 有 3–8 条失败（不是 1 条）；
3. 失败后下一次请求恢复正常，没有持续恶化；
4. 事后看 HikariPool-1 - Connection is not available 与 Leaked connection 都没有，说明不是池耗尽，而是单条连接被 LB 静默切断后，池子还在把它当 alive 发放。

初步判断：LB 的 350s 空闲超时 < HikariCP maxLifetime=1800s，且空闲期超过 350s 的连接（低峰期 minIdle 里躺着的）被 LB 单向 RST/FIN，但池子不知情；下一次 checkout 拿到这条「死连接」，第一次 query 才报错。批量出现是因为同一批连接在同一分钟窗口内被 LB 一起清掉。

【已尝试的排查与结果】

• 把 maxLifetime 降到 300s（< 350s LB 超时）：尖峰从每天 1–2 次降到 0–1 次，但连接重建频率上升 3–4 倍，DB 侧 Threads_connected 抖动变大，LB 侧新建连接 QPS 也上去了，团队担心长期下来对 LB/DB 都是隐性成本；
• 显式设 keepaliveTime=200s：尖峰基本消失，但每 200s 对每条空闲连接发一次 SELECT 1，minIdle=10 时约 3 QPS 的 keepalive 流量，DB 侧 Queries 计数被污染，慢日志 / 审计日志里混入大量 SELECT 1，排障时干扰大；
• 把 validationTimeout 从默认 5s 调到 1s：没观察到明显变化（怀疑这条链路根本没走到 validation）；
• 查了 HikariCP 5.x 的 connectionTestQuery 与 isConnectionAlive 路径，确认默认走 Connection.isValid(validationTimeout)，只有 checkout 时才校验一次——这就是为什么「死连接」会漏到业务侧。

【期望得到的答案形态】

1. maxLifetime 与 LB 空闲超时的关系：是「maxLifetime < LB 超时」就够，还是「maxLifetime + 抖动缓冲 < LB 超时」？多一层代理（LB + NAT + DB proxy）时缓冲怎么累加？有没有人踩过「LB 350s 但实际 340s 就断」这种非确定性的坑？
2. keepaliveTime 的取舍：在 800 QPS 的服务上，keepaliveTime 设 200s / 120s / 60s 各自的「keepalive 流量 vs 首请求失败风险」曲线，有没有人量化过？还是说应该彻底关掉 keepalive、靠 maxLifetime 短 + 业务侧重试？
3. 业务侧兜底：对「首请求失败」这种可预期的瞬时错误，是应该在 DAO 层加一次幂等重试（识别 SQLTransientConnectionException），还是应该在连接池层加「checkout 时强制 ping」？两者各自的性能代价和正确性风险（重试放大 / 非幂等 SQL 误重试）怎么权衡？
4. 可观测性：有没有人把「被 LB/代理静默断连」做成一个独立指标（比如 hikari_pool_stale_connection_recreated），而不是混在 connectionTimeout / leakDetection 里？具体怎么埋点？

我倾向的方案是「maxLifetime=300s + keepaliveTime=120s + 业务侧对 SQLTransientConnectionException 做一次幂等重试」，但 keepalive 流量和重试放大这两笔账我还没算清楚，想看看社区有没有更省的做法。