朋友公司大促期间，数据库连接池突然打满。所有需要数据库的请求都排队等连接，connection-timeout 设了 30 秒——等了 30 秒拿到连接的人还得用，30 秒拿不到的人直接报错。问题是那些等了 28 秒终于拿到连接的人，数据库早已经被前面的人压垮了，拿到连接也没用。400 个请求同时排队，300 个超时报错，100 个拿到连接但数据库响应时间从 5ms 飚到 500ms。 这不是数据库的问题，是连接池在突发流量面前没有自保能力。今天聊聊怎么用动态扩容和排队熔断，让连接池在洪峰到来时不崩溃。 问题：连接池是漏斗，不是水坝 连接池的设计初衷是"复用连接，避免频繁建连"。但它有一个致命假设：总有空闲连接可用。 突发流量一来，连接瞬间打满，后续请求只能排队。排队的请求占着 Tomcat 线程，Tomcat 线程也满了——连锁反应。 请求 → 连接池 → 没空连接 → 排队等 ↓ 排队占着 Tomcat 线程 ↓ Tomcat 线程池也满了 ↓ 新请求直接被拒 ↓ 整个服务不可用 连接池从"漏斗"变成了"堵点"。 方案一：动态扩容，峰值时多借几个连接 HikariCP 的 ....

一、连接池获取超时的痛点 上周，一位做支付系统的朋友吐槽：他们的系统在高峰期经常出现接口超时的问题，日志里大量报错 "Connection is not available, request timed out after 30000ms"。 "我们已经把连接池最大数调到了 50，"他说，"但还是不够用，一到高峰期就出问题。" 我查看了他们的系统，发现问题确实很严重： 系统在高峰期 TPS 约 2000 数据库连接池最大 50 个 平均接口耗时 150ms 理论上 50 个连接每秒能处理约 333 个请求，但实际高峰需要 2000 TPS 每次接口需要访问数据库 3-5 次 更关键的是，他们根本不知道连接都去哪了，是哪些SQL慢查询占用了连接，还是存在连接泄漏？ 二、传统排查方案的局限性 1. 手动查看日志 通过日志查看哪些接口慢、哪些SQL执行时间长。 这种方案的问题： 滞后性：问题已经发生，只能事后分析 信息不全：只知道某个接口慢，不知道当时系统整体状态 无法定位根因：看到的是表象，不是根因 耗时耗力：需要大量时间分析日志 2. 手动dump线程 通过 jstack 或 A....