朋友公司大促期间，数据库连接池突然打满。所有需要数据库的请求都排队等连接，connection-timeout 设了 30 秒——等了 30 秒拿到连接的人还得用，30 秒拿不到的人直接报错。问题是那些等了 28 秒终于拿到连接的人，数据库早已经被前面的人压垮了，拿到连接也没用。400 个请求同时排队，300 个超时报错，100 个拿到连接但数据库响应时间从 5ms 飚到 500ms。

这不是数据库的问题，是连接池在突发流量面前没有自保能力。今天聊聊怎么用动态扩容和排队熔断，让连接池在洪峰到来时不崩溃。

问题：连接池是漏斗，不是水坝

连接池的设计初衷是"复用连接，避免频繁建连"。但它有一个致命假设：总有空闲连接可用。 突发流量一来，连接瞬间打满，后续请求只能排队。排队的请求占着 Tomcat 线程，Tomcat 线程也满了——连锁反应。

请求 → 连接池 → 没空连接 → 排队等
  ↓ 排队占着 Tomcat 线程
  ↓ Tomcat 线程池也满了
  ↓ 新请求直接被拒
  ↓ 整个服务不可用

连接池从"漏斗"变成了"堵点"。

方案一：动态扩容，峰值时多借几个连接

HikariCP 的 maximumPoolSize 是写死的。但突发流量来的时候，可以临时扩大这个值：

正常：maximumPoolSize = 20
峰值：临时扩容到 30（保持 5 分钟）
恢复：回落回 20

Java 的 HikariConfigMXBean 支持运行时修改 maximumPoolSize：

HikariPoolMXBean mxBean = dataSource.getHikariPoolMXBean();

// 触发条件：等待连接数 > 10 且有超过 50% 的请求在排队
if (mxBean.getThreadsAwaitingConnection() > 10
        && 池利用率 > 0.9) {
    int newSize = Math.min(currentSize + 10, absoluteMax);
    mxBean.setMaximumPoolSize(newSize);
    log.warn("连接池扩容: {} → {}", currentSize, newSize);
}

但这个方案有个限制：不能超过数据库的最大连接数。 扩容前先确认 show variables like 'max_connections'，别把数据库也打爆。

方案二：排队熔断，等太久了别等了

排队本身不是问题，问题是无限制地排。你设了 connection-timeout=30s，请求就真的等 30 秒——30 秒后拿不到才报错。但在这个等待期间，数据库的负载还在增加，等到了连接也没意义。

熔断策略：不是等超时，而是主动拒绝。

请求来借连接：
  1. 如果排队人数 > 20 → 直接拒绝（不排队）
  2. 如果排队时间预测 > 2s → 直接拒绝（不排队）
  3. 如果连接获取成功 → 正常处理

这样做的效果是"快速失败"。请求被拒绝了，调用方可以走降级逻辑——读缓存、返回默认值、或者提示用户稍后重试。总比等了 30 秒再报错强。

Spring Boot 里可以配 HikariCP 的超时时间，但不能配排队熔断。需要在获取连接的调用方加一层拦截：

// 简易排队熔断器
public Connection getConnection() {
    int waiting = dataSource.getHikariPoolMXBean().getThreadsAwaitingConnection();

    if (waiting > MAX_QUEUE_SIZE) {
        throw new ConnectionPoolBusyException("连接池繁忙，排队人数: " + waiting);
    }

    return dataSource.getConnection(); // 正常获取（内部有 connection-timeout 保护）
}

方案三：业务降级，不依赖数据库也能活

连接池满的时候，不是所有请求都需要数据库。可以分层降级：

• 读请求：走 Redis 缓存，不走数据库
• 非关键写请求：进消息队列，异步处理
• 关键写请求：走连接池（这时排队压力已大幅降低）

降级开关根据连接池水位自动触发：

水位 > 80% → 只读缓存，写请求进队列
水位 > 95% → 只读缓存，写请求直接拒绝
水位恢复 → 恢复正常模式

三个方案不是互斥的，而是应该串起来用：动态扩容撑住第一波 → 排队熔断拦住后续冲击 → 业务降级保住核心链路。

总结

连接池突发流量的处理不是"多开几个连接就完了"。

动态扩容：临时扩大连接池，但上限不能超过数据库的 max_connections。峰值过了自动缩回去。

排队熔断：排队人数超过阈值直接拒绝，快速失败比熬到超时强。调用方走降级逻辑。

业务降级：连接池水位高了自动切缓存、切队列。非核心请求不抢数据库连接。

三条防线同时拉起来，大促高峰的连接池水位能控制在 80% 以内，不会出现"排队 30 秒然后超时"的崩溃链路。

有用的话转给还在把 connection-timeout 设成 60 秒的同事。