Redis 连接池这一层平时写业务代码的时候基本不会正眼看它。只要 Redisson 启动成功分布式锁能用、缓存能写能读好像一切就都正常了。可一旦并发上来你最先收到的报警往往不是 Redis 慢查询也不是 CPU 打满而是“连接池耗尽”“获取连接超时”这类听起来很底层、却能把整条链路拖死的错误。我之前在某个订单类的模拟项目里就撞上过一次接口压测到三千 QPS 时业务侧突然大量报错Redis 本身负载还不算高问题就出在 Redisson 连接池的分配逻辑和参数不匹配上。这篇文章就把这层窗户纸捅破讲清楚 Redisson 怎么通过底层 TCP 连接池和 Redis 通信、连接池的关键参数该怎么理解、不同业务规模下怎么估算和调优以及实际踩过的坑和排查思路。不管你是只用过 Redisson 写分布式锁还是已经在大型系统里负责缓存中间件治理这都能帮你少走一段弯路。1. 先搞明白Redisson 为什么需要自己的 TCP 连接池1.1 从一次“不设连接池”的代价说起如果你用 Jedis 写过原生代码应该记得早期版本里 Jedis 实例不是线程安全的很多人就每次操作都 new 一个连接出来。这样做最大的问题其实是 TCP 握手开销。Redis 通信本质上就是走 TCP 协议每次建立连接都要经历三次握手加上客户端和服务端各自分配文件描述符、缓冲区一次两次不明显几百 QPS 时延迟就会暴露出来。我用本地环境实测过每次新建连接再执行一条 SET 命令耗时大约比复用连接多出 0.2 到 0.5 毫秒如果再加上网络抖动这个差距会被进一步放大。更要命的是每条 TCP 连接在四次挥手之后主动断开的一方还会把端口留在 TIME_WAIT 状态一段时间高并发下如果一直新建短连接很快你就会看到一堆 TIME_WAIT 堆积在客户端主机上端口不够用新连接直接假死。所以客户端层必须有一个连接池把已经建立好的 TCP 连接放到池子里循环复用避免每次命令都重新握手。Redisson 也是一样只不过它的实现方式和 Jedis 那种同步阻塞式客户端有本质区别理解这一点后面再看配置项就会顺畅很多。1.2 Redisson 连接池的底层形态Redisson 底层通信用的是 Netty对每条 Redis 连接来说就是一个 Netty 的 Channel。它不像 Jedis 那样由一个 Apache Commons Pool 统一管 socket而是为每个 Redis 节点单独维护一组连接池。为什么要这么设计因为 Redisson 的价值定位不只是缓存客户端它承载了分布式锁、分布式集合、消息订阅、延迟队列这些高级特性不同的功能对连接的占用方式不一样混在同一个池子里管理会互相影响。在单节点模式下Redisson 至少会维护两类连接池一类是普通的命令连接池专门用来执行那些正常的读写命令另一类是订阅连接池用来支撑发布订阅、分布式锁的等待通知这类长监听场景。订阅连接通常需要长期占住一条 TCP 通道如果把它和普通命令连接放在同一个池子里就可能出现订阅任务把连接池占满、普通命令反而拿不到连接的尴尬局面。到了主从或者集群模式情况会更复杂一些。Redisson 会为每个节点独立维护连接池比如主从模式下有主节点连接池、从节点连接池集群模式下有多少个分片节点就有多少组连接池。有些配置项是全局的比如连接、命令执行的超时时间有些连接池相关的配置是按节点生效的比如每个节点各有多少连接数上限。你设置一个连接池大小的时候实际上是在设置“单个节点”的容量总连接数要再乘上节点数。这个点我见过好几个人理解错后面会专门细说。1.3 为什么连接池不是越大越好刚接触连接池调优的人很容易产生一种想法连接池设大一点多备点连接并发高的时候不就不缺连接了这句话在低并发下看上去有道理但在 Redis 场景里会带来两个隐蔽的副作用。第一个副作用是端口和文件描述符的占用。每个 TCP 连接在客户端是一个 socket 文件描述符在 Redis 服务端也对应一个 client 连接。如果你把连接池大小调到几百再一上集群总连接数轻松突破几千。Redis 默认的 maxclients 配置通常是 10000一个 Redis 实例还要被监控系统、运维脚本、其他客户端占用连接数真正留给业务的不可能全被你的连接池吃掉。第二个副作用是故障恢复变慢。连接池里的连接不是永远健康的Redis 服务端重启、网络闪断、防火墙超时都可能导致连接悄悄变成死连接。连接越多健康检查、重建、恢复的时间就越长。我在给某个监控类应用调参时试过把连接池从 64 调到 256结果 Redis 执行了一次 failover连接池恢复的时间反而比之前慢了不少原因是大量死连接重连产生了回退和超时风暴。连接池不是缓存空间不是越大越稳而是要刚好匹配你的并发模型。2. 连接池配置项的一一拆解与选参逻辑2.1 两个最核心的连接数参数Redisson 的每个节点连接池主要看两个配置connectionPoolSize 和 connectionMinimumIdleSize。前者是连接池里最多能同时保有的连接数上限后者是最低空闲连接数。可以这样理解连接池就好像一个餐厅预留的座位。connectionMinimumIdleSize 是保底预留的座位数不管有没有客人这些座位都摆好客人来了直接入座connectionPoolSize 是餐厅能摆下的最大座位数客人再多也不能超过这个数。如果同时来的客人数超过了最大座位数新来的客人只能排队等前面的客人离开。所以 connectionMinimumIdleSize 是连接池“预热”的关键。Redisson 在初始化的时候会默认向 Redis 预创建一些空闲连接使得一启动就有现成的连接可用而不是等第一条业务命令到了再临时建连。这个参数设置得太小冷启动时第一波请求会全砸在“创建新连接”上表现就是接口响应突然变慢然后慢慢稳定下来设置得太大又会白白占用资源。connectionPoolSize 则是整个连接池的容量上限。当一个业务线程使用完连接后连接会被归还到池子里如果当前连接数还没到上限新请求也想拿连接可以优先复用空闲连接如果暂时没有空闲连接就新建一条。当现有连接已经到达 size 上限且所有连接都处于忙碌状态新的请求只能等待。2.2 超时类参数为什么不能随便填除了连接数量参数另一组容易配置错误的是超时参数。Redisson 里常见的有三个connectTimeout、timeout、idleConnectionTimeout。connectTimeout 是建立 TCP 连接的超时时间也就是从客户端发起连接到 Redis 服务端接受这个连接的等待时间。这个值如果设得太小网络出现波动时就会出现大量连接建立失败如果设得太大Redis 不可用时会拖长故障感知时间业务线程一直阻塞在连不上 Redis 的状态里。timeout 是执行一条命令后等待响应结果的超时时间。它决定了业务线程最多愿意等 Redis 回复多久。这里有一个容易踩的坑timeout 设得太大Redis 变慢时命令超时不会立刻暴露反而会导致线程越积越多连接池很快被占满timeout 设得太小Redis 偶发的抖动就会变成大量超时报错甚至触发重试加重 Redis 的压力。通常我会建议控制在 1 到 3 秒之间再根据实际网络 RTT 做微调。idleConnectionTimeout 则是连接空闲多久后会被清理。假设业务峰谷明显深夜流量很低连接长时间没有数据读写网络设备很可能已经把这个连接断掉了但客户端还不知道。Redisson 通过周期性的空闲连接清理来避免这种情况。这个参数默认比较宽松一般不用动得太激进但如果你的服务会定期被纳管到容器编排平台的缩容策略中就要注意别让这个超时时间小于平台侧的连接空闲回收时间否则连接会被平台切断。2.3 重试和健康检查连接池疲劳时怎么办Redisson 的重试配置主要涉及 retryAttempts 和 retryInterval这一组参数决定了当命令执行失败时客户端会在连接层面做多少次重试、每次重试之间间隔多久。注意一点重试不是毫无代价的“保险丝”。如果 Redis 真的出现故障重试只会让请求在客户端多阻塞一段时间同时不断占用连接池里的连接。我在处理过一次故障后发现业务侧线程因为重试堆积短时间内把连接池里的连接全部占满后续所有新请求进入“获取连接超时”的恶性循环Redis 还没恢复客户端自己先被拖垮了。因此重试次数不建议设得太大常规场景下 2 到 3 次就足够了retryInterval 则可以设置在 500 到 1500 毫秒之间给 Redis 一点喘息空间。健康检查相关的还有一个 pingConnectionInterval 参数。Redisson 会定期对空闲连接发送 PING 指令确认连接仍然可用。这个机制对保持连接池里连接的健康状态非常重要尤其是在网络设备比较激进的场景下。这个值太小会额外增加 Redis 的负载我一般把它设置在 30 秒左右既能发现大部分“僵尸连接”也不至于产生明显开销。2.4 订阅连接池很多人忽略的第二张池子如果你只用 Redisson 做普通的键值读写订阅连接池可以不用管。但只要你用到发布订阅、分布式锁的等待通知、Redisson 的 RCountDownLatch 这类功能订阅连接池就会参与工作。订阅连接和普通命令连接不一样它是一种“长驻型”连接。当你的业务代码通过 Redisson 的 RTopic 订阅一个频道时这条连接需要一直挂在 Redis 上接收推送消息不会被频繁回收。如果订阅连接池太小新的订阅就无法建立如果订阅连接池设置得和普通连接池一样大又可能浪费资源。我见过一个应用用了 Redisson 分布式锁但 subscriptionConnectionMinimumIdleSize 没配置好默认值太小时锁竞争的等待场景下一旦并发上来就会出现通知消息发送不出去、锁释放延迟增大的现象。3. 实操配置与不同场景下的调优记录3.1 单节点模式下的基础配置示例在实际项目里Redisson 通常通过 YAML 或 Java 配置类来初始化。下面是我常用的单节点配置骨架先贴出来再一行行解释选参逻辑。singleServerConfig: address: redis://127.0.0.1:6379 connectionPoolSize: 32 connectionMinimumIdleSize: 8 subscriptionConnectionPoolSize: 10 subscriptionConnectionMinimumIdleSize: 2 idleConnectionTimeout: 10000 connectTimeout: 10000 timeout: 3000 retryAttempts: 3 retryInterval: 1500 pingConnectionInterval: 30000对应的 Java 配置是这样的Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setConnectionPoolSize(32) .setConnectionMinimumIdleSize(8) .setSubscriptionConnectionPoolSize(10) .setSubscriptionConnectionMinimumIdleSize(2) .setIdleConnectionTimeout(10000) .setConnectTimeout(10000) .setTimeout(3000) .setRetryAttempts(3) .setRetryInterval(1500) .setPingConnectionInterval(30000); RedissonClient client Redisson.create(config);这套配置适用于中低并发场景比如单机服务、QPS 在几百到一千左右的缓存访问。connectionPoolSize 取 32是因为这个量级下并发命令数通常远小于 32留出一定富余就能满足突发流量又不至于占用太多连接。connectionMinimumIdleSize 取 8是为了保证服务启动后立刻有连接可用不至于第一波请求都卡在建连上。timeout 取 3000 毫秒是基于局域网 Redis 访问通常在 1 到 2 毫秒内完成的背景3 秒已经宣告“这条命令大概率出问题了”。3.2 集群和哨兵模式下的连接池差异单节点配置切到集群或哨兵时连接池的规则会变这也是很多人配置完发现“连接数比预想多很多”的原因。先看集群模式。假设集群有 3 主 3 从共 6 个节点你在配置里设置了 connectionPoolSize 32那么 Redisson 会为每个主节点和每个从节点都准备一个连接池总连接数最大就是 6 * 32 192。更要注意的是读写命令默认是优先走主节点的从节点主要承担读流量如果你用只读操作的频率高还需要单独关注从节点连接池是否够用。哨兵模式类似Redisson 会动态感知主从切换。主节点和从节点分别维护连接池但它们自己是不知道“当前这个 Redis 是主还是从”的Redisson 会在后台订阅哨兵的消息来感知拓扑变化。这里有个隐含要求哨兵模式下连接池不能设置得太小因为 Redis 故障切换时新主节点一产生Redisson 会立刻向新主节点建立连接如果此时连接池已经满了且旧连接还没清理干净就会暂时出现“连接获取失败”。集群和哨兵本质上都是“多节点”拓扑所以配置时要遵循一个原则不要只盯着单个节点看要按“节点数 * 单节点连接池大小”来估算总连接数再对照 Redis 的 maxclients 配置留出余量。3.3 不同请求量级下的参数参考我整理了一张参数参考表这可以当作起点不要当成绝对标准。具体的值最终要以你的压测数据为准。业务特征connectionPoolSizeconnectionMinimumIdleSizetimeout适合场景低并发工具类应用QPS 5001643000ms定时任务、内部管理后台中等并发 Web 服务QPS 500-30003282000-3000ms常规接口连接复用为主高并发核心链路QPS 500064161000-2000ms秒杀、热点商品、订单写入读写分离且读多写少主 32 / 从 64主 8 / 从 162000ms查询量远大于写入量的场景这张表的估算逻辑是这样的一条 Redis 命令在局域网内的耗时通常在 1 到 3 毫秒一个连接在 1 秒钟内大约能支撑几百次串行命令如果你用的是 Redisson 的同步 API每个请求会占用一个连接直到拿到响应。以 QPS 5000 为例假设平均命令耗时 2 毫秒理论上每个连接每秒可以处理约 500 条命令10 个连接就够用了。但实际请求会有波动、有多条命令合并执行的情况还要留出容错空间所以连接池取 32 到 64 是一个安全区间。我一般建议先按“并发线程数有几个”来反推连接池大小而不是按总 QPS这样更贴近真实资源占用。提示理论上一个连接可以串行跑很多命令所以连接池不等于 QPS 上限。如果你的并发线程数只有 20就算 QPS 很高连接池取 32 也足够如果线程数是 200连接池至少得能覆盖大多数线程同时取连接的峰值。3.4 调优结果的验证方法参数调完不是拍脑袋就觉得好了我一般看三个信号判断调优是否到位。第一个信号是从客户端观测到的命令耗时。如果压测期间 P99 耗时没有因为连接池调整而明显抬升且没有出现“等待连接”导致的耗时尖刺就说明连接池容量基本合适。第二个信号是 Redis 服务端看到的连接数。在压测进行中持续执行 Redis 的 INFO clients 命令观察 connected_clients 的变化曲线。如果这个数稳定在某个区间并且远低于 maxclients 的 80%说明连接数设置留有安全余量如果连接数直逼 maxclients那就需要缩连接池或者考虑拆分客户端。第三个信号连接池自身的分配情况。Redisson 在一些版本里提供了节点状态查询能力可以通过客户端的通道统计看到当前已用连接数、空闲连接数配合监控平台的指标曲线就能判断连接池是否存在持续被打满的情况。我看监控的时候习惯关注“等待获取连接的线程数”而不是仅看连接池用量等待线程数突然上涨通常是连接池不足的早期信号。4. 高频故障与排查实录4.1 连接池耗尽RedisConnectionException 与等待获取连接面目最狰狞的报错就是连接池被完全占满。表现是业务侧开始大量报 RedisConnectionException提示无法从连接池获取连接或者是连接等待超时。我第一次遇到这个问题时第一反应是加连接池大小。结果加了之后报错确实缓解了但过了几周又出现。后来一查才发现根因根本不在这某个定时任务在处理一批数据时用了 Redisson 的同步 API而且在一个循环里获取了几万个分布式锁每个锁的获取和释放之间还夹杂着耗时操作。这个任务一跑相当于几万个线程同时在等待锁连接池就被这些等待操作全部占死。正确的处理办法应该分两步第一步先看代码里是否存在长时间占用连接然后阻塞的操作比如把多个 Redisson 调用串在一个大事务里或者在分布式锁的 tryLock 里塞了太多业务逻辑第二步再考虑调整连接池。如果确认是业务使用方式导致的光调连接池等于治标不治本。4.2 连接泄漏并发明明不高连接数却一直在涨还有一种更隐蔽的情况压测 QPS 很低大概只有几百但 Redis 服务端看到的连接数却在持续上涨最后稳定在一个远超预期的值。连接数一直涨通常有几种可能。一种可能是 Redisson 的订阅连接没有被及时关闭。比如业务代码里每次操作都创建一个新的 Redisson 客户端用完却不调用 shutdown连接就会越积越多。另一种可能是使用了 Redisson 的分布式锁但业务线程异常退出时没有释放锁看门狗机制会持续保持在线的状态连接自然也不会释放。我处理过一个案例某个同学在循环里用 RTopic.subscribe 订阅了一个频道每轮循环都创建新的订阅但旧订阅没有调用 unsubscribe结果连接数每一轮循环就往上涨几个。这类泄漏的排查思路很直接先跑到 Redis 服务端执行 CLIENT LIST看这些连接的客户端属性是什么确认是订阅连接、普通命令连接还是其他类型再结合监控曲线看它是从一开始就往上涨还是某个功能上线后才开始涨。定位到类型之后处理办法就清晰了。注意Redisson 在正常编程模型下连接不需要开发者手动申请和释放因为它内部做了借还管理。但订阅类操作和自定义 RedissonClient 实例的生命周期一定要自己管好否则就会出现“池子里不缺连接但整体连接数一直涨到爆”。4.3 TIME_WAIT 堆积与系统参数调整有一类问题和连接池本身无关但排查的时候经常混在一起就是 TIME_WAIT 堆积。当客户端和 Redis 频繁建立和断开 TCP 连接时主动断开的一方会先进入 TIME_WAIT 状态持续一段时间后才会释放端口。在 Linux 环境里这个持续时间默认是 60 秒左右。如果你的连接池设置合理连接是复用的TIME_WAIT 会很少但如果有大量连接被新建和关闭比如连接池设置过小导致连接频繁淘汰重建或者服务端重启导致一堆连接同时断开TIME_WAIT 数量就会激增。检查方法是执行netstat -nat | awk {print $6} | sort | uniq -c | sort -rn看到 TIME_WAIT 数量达到几万的时候就要警惕端口耗尽。一些运维经验会建议调整内核参数 tcp_tw_reuse、tcp_tw_recycle 来快速回收但我不建议一上来就动内核参数尤其是 tcp_tw_recycle 在不少现代内核版本里已经不再建议开启容易引入更诡异的问题。更安全的做法是先确认连接池复用是否正常、是否有代码在频繁创建客户端实例从源头减少断连次数。4.4 初始化超时与连接池预热有些服务只要一重启启动阶段就会出现大量连接失败或者初始化超时。原因往往出在连接池预热和 Redis 服务端的压力冲突上。当服务刚刚启动时Redisson 会根据 connectionMinimumIdleSize 往 Redis 预创建一批连接。如果 Redis 服务端同时被几十个服务实例启动时的预热连接同时冲击服务端就可能暂时拒绝新建连接导致初始化超时。这在容器化环境、服务多副本同时扩容时特别明显。解决思路通常有两个一是把 connectionMinimumIdleSize 适当调小让连接池进入“懒加载”模式启动时只创建少量连接后续按需补充二是在服务启动后做一个“预热请求”比如初始化时主动执行几条简单的 Redis 命令让连接池先建立足够的连接避免高峰期一边扩容连接一边处理真实业务。4.5 Redis 故障切换后连接池不恢复主从哨兵集群发生故障切换时Redisson 会自动感知新主节点并更新连接池。但在实际运维中切换过程偶尔会出现连接池短暂不可用的情况。排查这类问题时要区分两层原因。第一层是 Redisson 是否感知到了拓扑变化。可以观察客户端日志看有没有节点上下线的记录。第二层是连接池的容量有没有被切换瞬间的并发操作打满。故障切换时所有原本打到旧主节点上的写请求会同时转向新主节点如果连接池上限不够就会出现短时间内的连接竞争表现为切换后前几秒请求大量超时。针对这种情况我会把哨兵或集群模式下的 connectionPoolSize 在上限值的基础上多预留 20% 到 50% 的冗余尤其对那些不能容忍间歇性失败的场景这点冗余非常值得。5. 最后聊聊连接池调优之外的事参数调来调去最后拼的还是对业务并发模型的理解。我个人踩过几次坑之后的体会是不要单纯拿“调参脚本”去套所有项目也不能指望靠一个截图里的推荐配置包打天下。连接池大小本质上是对“你系统里同时会有多少个线程活跃地访问 Redis”的一次预估。预估偏了调什么都没用。所以我建议每个真正用到 Redisson 的团队至少在项目上线前做两件事一是把连接池相关的关键指标接进监控包括已用连接数、等待获取连接的线程数、命令 P99 耗时二是在压测环境里主动做一次 Redis 故障切换演练看看连接池在异常状态下的恢复速度。这两件事不需要多复杂的平台能力但对避免线上事故帮助极大。最后一个很实用的小技巧排查连接相关问题时第一步永远是去看 Redis 服务端的 CLIENT LIST 输出而不是只盯着应用日志。应用日志只能告诉你“连接拿不到了”CLIENT LIST 能告诉你连接是谁建立的、是哪个客户端实例建立的、处于什么状态。定位问题先从最底层的数据出发往往比在代码里猜效率高得多。