确认连接池耗尽而非redis宕机：先执行redis-cli info clients | grep connected_clients和redis-cli config get maxclients，若connected_clients接近maxclients且日志出现“err max number of clients reached”或“could not get a resource from the pool”，即为客户端连接池耗尽。
连接池耗尽不是Redis服务端崩了，而是客户端没管好连接生命周期，或者池子大小和业务节奏对不上。
怎么确认是连接池耗尽而不是Redis挂了
先别急着调参，用两行命令快速定位：redis-cli info clients | grep connected_clients 查当前活跃连接数，redis-cli config get maxclients 查服务端上限。如果 connected_clients 接近 maxclients，且应用日志里反复出现 ERR max number of clients reached 或 Could not get a resource from the pool，基本就是连接池卡住了。
注意：这不等于 Redis 本身负载高——CPU 和内存可能都很闲，但连接数已经焊死在上限。
Jedis/Redisson 连接池关键参数怎么设才不踩坑
Java 生态里最常出问题的是 maxTotal、maxIdle、minIdle 和 maxWaitMillis 四个参数。它们不是越大越好，也不是固定值：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
maxTotal建议设为应用部署节点的 CPU 核心数 × 2～4，比如 8 核机器配 16～32；超过这个值，线程争抢连接反而拖慢响应 -
minIdle不要设 0，至少给 2～5 个“常驻”连接，应对突发流量，避免每次突增都要新建连接 -
maxWaitMillis必须设（比如 100～500ms），否则线程会无限等待，最终拖垮整个线程池 -
testOnBorrow在生产环境慎开——每次取连接都做 ping 检测，QPS 高时开销明显；改用testWhileIdle+timeBetweenEvictionRunsMillis更稳妥
为什么连接数一直涨不降？重点查这几处泄漏点
连接池配置再合理，代码漏关连接也白搭。高频泄漏场景集中在：
- 没用 try-with-resources 或没在
finally块里调jedis.close()/redissonClient.shutdown() - 异步任务（如 CompletableFuture）里获取连接后，异常分支没回收连接
- Spring Boot 中误配了
@Bean的作用域，把JedisPool声明成prototype，导致每个请求都新建池子 - HTTP 客户端（如 WebClient）或消息队列消费者里，Redis 操作嵌套在长生命周期对象中，连接随对象驻留不释放
用 redis-cli client list 查看连接来源 IP 和 idle 时间，idle 超过 5 分钟还挂着的连接，大概率是泄漏源。
单实例扛不住时，别只想着加 maxclients
盲目调大 maxclients 会撞上操作系统文件描述符限制（ulimit -n），还可能压垮 Redis 实例本身。更可持续的做法是：
- 横向拆分：按业务域或用户 ID 分片，把一个大池子变成多个小池子，各自隔离
- 读写分离：只让写操作走主节点连接池，读操作走从节点池，降低主节点连接压力
- 引入代理层（如 Twemproxy 或 Redis Cluster 官方客户端），由中间层做连接复用，客户端只需管少量连接
真正难的不是算出该配多少连接，而是让每次 getResource() 都能对应一次 returnResource() —— 这部分逻辑一旦散落在十几处业务代码里，监控和修复成本就远高于初期加个统一封装。
