连接池配置核心参数：最大连接数、最小空闲连接、连接超时时间
讲熔断之前，咱们得先把连接池那些“拧螺丝”的参数聊透。你想想看，熔断器再聪明，如果连接池本身配置得离谱，它也只能干瞪眼。我在好几家公司的线上事故复盘里，最后都追到了这里——连接池参数设得不对，熔断提前触发或者压根儿不触发。
这一节咱们就盯死三个最关键的参数：最大连接数、最小空闲连接、连接超时时间。这三个参数互相拉扯，直接影响熔断器什么时候“跳闸”。
最大连接数（maxTotal）—— 你得知道自己能扛多少人
最大连接数，说白了就是连接池能同时持有的连接上限。我见过最离谱的配置是直接设成 10000，心想“我业务量大，越多越好”。结果数据库那边连接数被打满了，CPU 爆红，然后熔断器因为响应超时全开了。这锅到底是连接池背还是熔断器背？其实锅在最大连接数设得太高。
怎么定这个数？我的习惯是先压测，拿到数据库能稳定处理的最大并发连接数，然后打八折。比如压测下来单库能扛 500 连接，那池子就给 400。留点余量给管理连接和突发高峰，但不至于把数据库撑死。
配套的参数还有 maxWaitMillis（获取连接的超时时间）。如果连接池里没空闲连接、也达到上限了，新请求会等 maxWaitMillis 毫秒。等到超时再抛异常，这时熔断器就可能被触发。我一般把这个值设成 50ms 以内——等太久，上游超时都给拖死了。
最小空闲连接（minIdle）—— 别让熔断器等得冒烟
最小空闲连接，是保证连接池里随时有这么多空闲连接“站岗”。为什么要设这个？你想想，如果 minIdle=0，流量低峰期连接池全回收了，突然来一波高峰期，所有请求都得等新建连接。建连接慢（尤其是 SSL 握手），接口响应变长，熔断器一看“哎，超时了”，直接开闸——其实只是连接池没准备好。
我个人习惯：把 minIdle 设成业务低谷期所需连接数的平均值。比如半夜零点 TPS 只有 100，每个连接处理 10 TPS，那同时只需要 10 个连接，我就设 minIdle=10。这样流量一上来，池子里有“现役兵”，不用临时招兵买马。
但注意别设太大。我有一次把 minIdle 设成了 200，结果连接池始终占用 200 个数据库连接，数据库那边报“too many connections”。那熔断器直接因为资源耗尽而全熔断，连健康检查都打不过去。所以 minIdle 是双刃剑——太少会导致冷启动熔断，太多会浪费资源导致熔断。
| 场景 | minIdle 设置建议 | 潜在风险 |
|---|---|---|
| 高并发、快速波动 | 设成业务高峰期的 20%-30% | 偏大，但能避免冷启动熔断 |
| 平稳流量、定时任务 | 设成 0 或极小值 | 突发流量可能触发熔断 |
| 数据库连接数受限 | 设成 maxTotal 的 50% 以内 | 设太大导致数据库连接耗尽 |
连接超时时间——熔断器的“导火索”
连接池涉及三种超时，很多人混为一谈。我踩过的大坑就是只配了一个超时，结果全乱套。
- connectTimeout：TCP 三次握手超时。如果数据库挂了或网络抖动，这个超时很快（比如 1 秒）就能让连接建立失败。我一般设 1~3 秒，再长也没意义。
- socketTimeout：等待数据库返回数据的时间。也就是发了一个 SQL 后，网络层多久没收到包视为超时。这个要根据接口的 P99 来设，我习惯设成接口 SLO 的 80%。比如接口要求 100ms 返回，那 socketTimeout 设 80ms，不满足就报错，熔断器正好拿这个错误计数。
- waitTimeout（获取连接超时）：就是上面说的
maxWaitMillis。池子里没空闲连接且达到上限后，请求等多久。我建议设成 10~50ms，别让请求在池子里死等。
三种超时配合起来，决定了熔断器看到的错误率和响应时间。你想想看：如果 connectTimeout 设得跟网络超时时间一样长（比如 10 秒），一次网络故障就能让前端等 10 秒，熔断器早该在 2 秒就断开了。所以这三个超时一定要比业务端的整体超时 短，而且要有阶梯：connectTimeout < socketTimeout < waitTimeout < 业务超时。
一张图看清参数与熔断的关系
下面这张图梳理了客户端请求如何经过连接池，最终影响熔断器。注意每个参数在哪一步起作用。
好了，这三个参数你现在应该有数了。下次有人问你“为什么熔断器总是误触发”，你可以先查查 maxTotal 是不是设得太保守导致请求排队，或者 socketTimeout 是不是太宽松变成了“慢请求黑洞”。调好它们，熔断器才能帮你干正事，而不是添乱。