接手过Redis相关服务的人迟早都会面对“连接”这道坎。Linux有句老话叫一切皆文件Redis这道坎里藏着的则是连不上、连上了断、连多了打满。Redisson作为Java里用得越来越广的Redis客户端很早就不再走Jedis那套直连思路而是把TCP连接管成了池。这篇文章就围绕Redisson的Redis TCP连接池展开说说它的设计逻辑、核心参数怎么配、不同部署模式下怎么落以及我实际踩过的坑。适合正在用Redisson做分布式锁、缓存或者消息队列的团队也适合那些在连接池配置上犹豫不决、想搞清楚到底该调哪个参数的人。1. Redisson的连接池到底管的是什么1.1 为什么非要用TCP连接池Redis本身是单线程处理命令的服务端但客户端作为发起方如果每次都新建TCP连接去发命令代价是非常明显的——一次完整的TCP握手加挥手最快也要消耗一两个RTT在高并发场景下这个开销会被无限放大。更进一步说每一次连接的建立和销毁都会在操作系统层面留下一段TIME_WAIT状态连接高频率地建了又删端口资源会慢慢耗尽。连接池的思路其实和线程池类似提前创建一批连接放进池子里用的时候借出来用完还回去。把建立连接这个高频且昂贵的动作从每次请求里剥离开让它变成池子初始化时的一次性动作。Redisson的Redis TCP连接池正是干这件事的它把对Redis的所有读取和写入都放到池化的连接上执行减少握手开销同时借助池子限制并发连接数避免客户端把服务器连接数量顶爆。我之前在某个高并发抢券项目里最开始用的是每次请求新建连接的写法压测到两千QPS时监控上出现了大量TIME_WAIT服务端连接数也涨到了几千。后来整体切到Redisson连接池连接数稳定在几十服务端压力骤减。这就是连接池在当前场景里最直接的价值。1.2 Redisson和Jedis的连接管理逻辑差异很多人会把Redisson的连接池理解成JedisPool的翻版其实两者的底层机制完全不同。JedisPool是典型的使用方借还模式每个Jedis实例绑定一个物理Socket业务线程从池子里拿一个实例用完调用close归还。简单粗暴但问题在于池子内的连接对象和物理连接的生命周期完全绑定一旦网络抖动或者Redis主从切换连接失效需要重建JedisPool只能靠池内驱逐逻辑来处理。Redisson则不是这样。它底层的连接管理由Netty来做每个Redis连接被包装成Channel而Channel之上又有CommandService和连接池管理器。Redisson会把一个物理TCP连接切成逻辑上的并发命令通道多个业务请求可以复用同一个物理连接发送命令通过Promise关联各自的响应。这样设计的直接好处是连接数量不需要随并发线性增长——几百个并发操作共享一二十个连接也没问题而不是像Jedis那样一个并发要求一个连接。理解了上面这个差别就能明白为什么Redisson连接池参数通常比JedisPool里的maxTotal小很多依然能支撑很高的吞吐。同时也说明配置Redisson连接池时不能照搬Jedis那套调参经验需要从命令复用和物理连接健康两个维度重新考虑。2. Redisson连接池核心配置项逐个说清楚2.1 需要重点关注的一系列参数Redisson的配置对象或YAML里和TCP连接池直接相关的参数集中在几个位置。最常用的单机模式里重点是看connectionPoolSize、connectionMinimumIdleSize、timeout这几个如果部署在集群或哨兵模式还要额外关注每个Redis节点的连接池参数。connectionPoolSize是池子中允许的最大连接数这个参数决定了请求瞬间并发走Redis时的最大并行连接量。需要注意它并不是Redis客户端的并发上限因为Redisson会在一条物理连接上复用多路命令但也不能无脑调高每个连接都会占据服务端的一个文件描述符同时也会占用本地内存。connectionMinimumIdleSize是池子中保持的最小空闲连接数。设置这个值的目的在于当请求高峰期突然来临时不需要临时新建连接而是可以直接从池子里拿已经空闲的Channel。如果你能确定业务有比较规律的波峰和波谷把这个值设置为波谷时段的平均连接需求是比较合理的做法。timeout指的是从连接池中获取连接的等待时间单位是毫秒。当请求到达且池子内没有空闲连接同时连接数已经达到connectionPoolSize上限时新的请求会等待这个时间超时后抛出异常。这个值不宜设得太长否则会让调用线程长时间阻塞拖垮系统的整体响应但也不宜太短否则在瞬时流量尖峰时容易误伤正常请求。idleConnectionTimeout控制的是空闲连接被回收的时间。连接在池子里空闲超过该时间Redisson会主动关闭。这个参数要和Redis服务端的timeout配置一起看——如果服务端设置了空闲断开时间客户端的idleConnectionTimeout设置得比服务端长连接就会被服务端先断开而客户端还认为连接可用这就是常见的“偶发连接不可用”根因之一。pingConnectionInterval是心跳探测间隔Redisson会定期用PING命令检查池中连接的健康状态发现失效连接会主动剔除并重建。网络环境不稳定的情况下这个值可以适当调小更快感知断开的连接。以上这些参数的默认值和调优建议可以参考下表的整理。参数名默认值单机模式核心作用调优建议connectionPoolSize64最大活动连接数按并发量推算不要盲目加大connectionMinimumIdleSize10最小空闲连接数贴合低谷流量设置保证突发时够用timeout3000ms获取连接的超时时间不建议超过业务接口的SLAidleConnectionTimeout10000ms空闲连接回收时间必须小于服务端空闲断开时间pingConnectionInterval30000ms心跳探测健康状态网络抖动频繁时适当减小connectTimeout10000ms建立TCP连接的超时内网可调小跨机房要调大2.2 配置时最容易踩的隐性问题第一类容易踩的问题是连接池参数孤立地看没有结合整个Redis节点的连接数上限来考虑。很多云厂商的Redis实例默认最大连接数是10000但如果你部署了多个服务实例每个服务实例又注册了多个Redis连接加起来乘以节点数很快就会逼近服务端上限。这个不是Redisson本身的问题而是容量评估的问题但确实在配置连接池时最容易忽略。第二类问题是单机模式、主从模式、集群模式下连接池参数名称看起来很像作用却不一样。单机模式里connectionPoolSize管的是唯一一个节点的连接而集群模式里masterConnectionPoolSize和slaveConnectionPoolSize分别负责主节点和从节点。把集群模式里的读多写少业务配置成“主从连接池都调大”不仅浪费还会在主节点上形成无谓的连接压力。第三类问题是对timeout的误解。曾经有同事把timeout理解成“Redis命令执行超时”结果把它设成了50毫秒在Redis慢查询出现的瞬间大量线程都在限额上不必要地抛异常。实际上Redisson里命令本身的超时是另一个配置和连接池获取连接的等待时间要分开理解。连接池层面的timeout只负责控制“池子中拿不到连接时能等多久”。3. 不同部署模式下的连接池配置实战3.1 单机模式从YAML到编程式配置最典型的使用场景还是单机模式。一个Redis实例一个Redisson客户端配置最简洁。这里需要注意Redisson支持YAML、JSON、编程式三种方式多数项目里用YAML或编程式比较多。先看YAML配置方式这是一份可以直接用的最小配置singleServerConfig: address: redis://127.0.0.1:6379 password: null database: 0 connectionPoolSize: 64 connectionMinimumIdleSize: 10 connectTimeout: 10000 timeout: 3000 idleConnectionTimeout: 10000 pingConnectionInterval: 30000程序启动时通过Redisson的配置加载入口读取这份YAML就能得到一个具备默认连接池配置的RedissonClient。我在本地开发环境通常会把connectionPoolSize降到16把connectionMinimumIdleSize降到2因为开发环境的并发量根本用不到那么多连接减少连接占用也可以让本地IDE调试时减少Socket数量避免一些端口相关的困扰。如果偏好编程式配置可以这样写Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setConnectionPoolSize(64) .setConnectionMinimumIdleSize(10) .setConnectTimeout(10000) .setTimeout(3000) .setIdleConnectionTimeout(10000) .setPingConnectionInterval(30000); RedissonClient client Redisson.create(config);两种方式最终生效的参数一致选择哪种主要看团队习惯。不过有一个细节值得提醒如果你的配置中心是Apollo或Nacos想要动态修改连接池参数编程式配置会更容易实现因为可以在运行期重新构建Config并创建新的RedissonClient实例。YAML配置则通常需要重启应用才能生效。3.2 集群和哨兵模式下连接池参数怎么变单机模式切换到哨兵或集群模式后连接池参数的配置位置和粒度都会发生变化。先说哨兵模式Redisson的哨兵配置里有一个masterConnectionPoolSize和一个slaveConnectionPoolSize分别对应主节点和从节点的连接池大小同时也有各自的connectionMinimumIdleSize。哨兵模式下读写通常会分流读操作走从节点写操作走主节点。如果你的业务读多写少从节点的连接池可以适当调大主节点保持默认即可。集群模式比哨兵更复杂一点。Redisson针对每个集群主节点都会建立一个连接池配置项同样区分主从。集群里的每个master节点承载部分槽位的数据所以多个master节点之间的连接池配置会直接影响分片访问的并发能力。这里要特别提醒一点如果你的集群有3主3从那么masterConnectionPoolSize配置的是每一个主节点的连接池大小而不是全部主节点共享一个池子。也就是说3个主节点总共的连接上限是3乘以该配置值评估服务端连接数时要按照这个逻辑来算。来看一段集群模式配置示例clusterServersConfig: nodeAddresses: - redis://127.0.0.1:7000 - redis://127.0.0.1:7001 - redis://127.0.0.1:7002 masterConnectionPoolSize: 48 masterConnectionMinimumIdleSize: 8 slaveConnectionPoolSize: 48 slaveConnectionMinimumIdleSize: 8 timeout: 3000 idleConnectionTimeout: 10000 pingConnectionInterval: 30000很多人在集群模式下会犯的错误是把每个节点的池子都设得和单机模式一样大以为这样能提高吞吐。实际上在多分片集群里单节点连接数只需要达到一定规模就能打满该节点的CPU再往上加连接只会增加内存占用和服务端文件描述符消耗吞吐几乎没有变化。集群场景下更值得关注的是“槽位分布是否均匀”和“慢查询是否集中在某个节点上”连接池只是托底保障。4. 性能调优连接池到底要多大才合理4.1 推算连接池大小的思路连接池参数没有绝对的标准答案但可以通过一套简单推算来找到合理区间。核心思路是看两件事业务侧的请求QPS以及单次请求在Redis上平均耗时。假设一个接口每秒钟需要发起2000次Redis命令操作单次操作在Redis服务端的平均处理耗时是1毫秒那么同一时刻正在执行中的命令数量理论上是2000乘以0.001也就是2个并发。这个算出来的数字看起来很小但考虑到连接复用、命令排队、网络抖动等因素实际需要的连接数会比理论值稍高。常见的策略是把理论并发数乘以2到3倍作为连接池的基准值。再看真实场景。某个业务高峰期QPS是4000平均单次Redis命令耗时1.5毫秒那么理论并发就是4000乘以0.0015等于6个并发连接。把基准值放大到3倍得到18个连接。也就是说connectionPoolSize设置在20左右已经完全可以满足这个业务的吞吐需求再往上加连接并不会带来吞吐提升。我在实践中发现连接池参数的调节之所以难是因为瓶颈往往不在连接数本身而在于Redis单线程的处理能力。如果一个Redis实例的CPU已经打满连接池从50调到500也无法改善延迟。这时候优先要做的是定位慢查询、拆分大Key、把热点数据分层处理单纯调大连接池只会让请求在服务端排队时堆积更多。4.2 实测中看到的连接池性能拐点用压测数据说话会更直观。某次我对一个基于Redisson的服务做全链路压测配置从connectionPoolSize16开始逐步上调记录了对应的P99延迟和客户端错误数。连接数从16调到32时P99延迟明显下降错误率也降了。从32调到64时P99微微下降但收益已经很小。从64调到128时P99几乎不变错误率也没有变化而客户端的内存占用和服务端文件描述符数量却在上升。这说明在这个具体压力模型下连接池的合理区间在32到64之间超过64就是纯浪费。这个实验让我确认了一个观点——连接池并不是越大越好它只是在满足并发需求的前提下尽量保持最小的连接数量减少资源开销和问题暴露面。判断连接池是否合理不应该只看连接数还要关注P99延迟、错误率、服务端连接数这三个指标的组合。只要P99稳定、错误率为零连接池小一点反而是好事。另外提醒一句压测环境需要模拟真实的网络条件。如果压测客户端和Redis服务之间走的是本机回环网络RT会比真实环境低很多推算出的连接池大小也会偏小。跨机房或者云环境部署时RT通常会翻几倍连接池需要相应调整。5. 踩坑记录Redisson连接池的典型问题排查5.1 连接池耗尽Connection pool is exhausted这个异常应该是Redisson连接池最常见的报错报错信息里会明确提示连接池已满无法立即获取连接。第一次遇到时我下意识觉得是并发量太大直接把connectionPoolSize往上调结果发现治标不治本。后来排查才发现真正的问题出在服务端一个慢查询上——某个大Key的HGETALL操作耗时接近1秒大量请求在同一时间占住了连接后面的请求只能在池子里排队等。排查顺序可以按这个来先看Redis慢日志确认有没有单条耗时很长的命令再看服务端的connected_clients数值确认服务端实际连接数是不是达到上限最后再看客户端错误发生的时间段和业务高峰是否吻合。如果慢查询是偶发性的处理慢查询比调大连接池更有效如果确实是并发超高再考虑增加连接池大小或增加Redis节点分摊压力。另外还有一种隐蔽情况。业务代码里使用了Redisson的分布式锁或信号量但忘记在finally块中释放或者使用了RedissonClient获取RMap之后长期持有而不关闭也会导致连接无法归还。这类连接泄漏不会报错但会让连接池里的可用连接慢慢减少最终表现为偶发的连接池耗尽。排查时可以通过JMX或者框架自带的Metrics观察池内活跃连接数和空闲连接数的趋势。5.2 网络抖动导致的连接失效与重建Redisson底层虽然有Netty帮你管理和重建连接但网络环境的抖动还是会在某些瞬间暴露出来。最典型的现象是某一段时间内客户端日志没有任何异常但Redis服务端发现一批连接被断开紧接着Redisson客户端重新建连。这种问题的根源多半是idleConnectionTimeout和服务端timeout配置冲突。比如Redis服务端设置了timeout 300意味着空闲超过300秒的连接会被服务端断开而Redisson的idleConnectionTimeout默认是10000毫秒也就是10秒。这里看起来10秒远小于300秒不会触发问题。但如果有人把服务端timeout调成了5秒而Redisson的idleConnectionTimeout依然是10秒就会导致连接在客户端不知情的情况下被服务端断开。要避免这个问题建议把idleConnectionTimeout和Redis服务端的timeout对齐并且让前者比后者小20%到30%。同时pingConnectionInterval可以适当调低比如从默认的30秒调到10秒让客户端更频繁地确认连接健康状态一旦发现失效连接就及时剔除并重建避免业务线程用到坏连接。5.3 排查连接池问题的实用工具箱连接池问题排查起来光看日志是不够的还需要几个常规工具配合使用。Redis服务端执行INFO clients可以查看当前连接数、连接数上限、最近拒绝的连接数。CLIENT LIST可以列出所有客户端连接的详细信息包括连接的空闲时间、最后执行的命令方便判断哪些连接长时间空闲或异常占用。Redis的SLOWLOG GET可以随时查看最近执行的慢命令如果连接池耗尽前的某个时间点正好有慢命令基本就能锁定方向。客户端侧如果你的项目引入了Micrometer或者Spring Boot ActuatorRedisson会暴露一部分连接池指标比如连接数、空闲连接数、等待获取连接的线程数。这些指标可以接到监控系统里配合告警规则在连接池使用率超过阈值时提前预警而不是等到报错了才去查日志。还有一个容易被忽略的经验连接池相关的报错经常不是由Redisson自己抛出来的而是在业务调用分布式锁、读缓存、发消息时被包装成各种业务异常。排查时不要只看业务堆栈要往底层Redis操作那一行追溯通常能看到RedisConnectionException或者TimeoutException的影子顺着这个线索才能找到连接池层面的原因。6. 几个实用的经验值直接拿去用最后分享几个我在项目中沉淀下来的经验值。这些数字不是从文档里抄的是结合若干次压测和线上问题总结出来的可以作为你配置连接池时的起点。大多数内部系统的单机Redis服务connectionPoolSize设置在32到64之间就足够了如果只是本地开发或测试环境16就够用。connectionMinimumIdleSize设置为connectionPoolSize的四分之一到三分之一比较合适既能保证突发流量下有一定缓冲又不会让太多空闲连接白白占用资源。timeout按业务SLA来定内部接口一般2到3秒外部接口涉及Redis的部分最好别超过1秒。如果业务里大量使用Redisson的分布式锁获取锁的等待时间会导致线程在连接池上排队的时间变长此时connectionPoolSize需要在普通推算基础上上浮一些。但更推荐的做法是排查锁持有时间是否有优化空间而不是无限调大连接池。因为分布式锁本身是串行化资源连接池再大也不能让锁的并发能力提升。另外多环境部署时连接池参数不要复制粘贴。预发环境和生产环境的流量模型完全不同用相同的连接池配置要么预发浪费资源要么生产环境不够用。建议把连接池参数做成可配置项每个环境单独调整上线前用压测数据来验证而不是靠直觉。
接手过Redis相关服务的人迟早都会面对“连接”这道坎。Linux有句老话叫一切皆文件Redis这道坎里藏着的则是连不上、连上了断、连多了打满。Redisson作为Java里用得越来越广的Redis客户端很早就不再走Jedis那套直连思路而是把TCP连接管成了池。这篇文章就围绕Redisson的Redis TCP连接池展开说说它的设计逻辑、核心参数怎么配、不同部署模式下怎么落以及我实际踩过的坑。适合正在用Redisson做分布式锁、缓存或者消息队列的团队也适合那些在连接池配置上犹豫不决、想搞清楚到底该调哪个参数的人。1. Redisson的连接池到底管的是什么1.1 为什么非要用TCP连接池Redis本身是单线程处理命令的服务端但客户端作为发起方如果每次都新建TCP连接去发命令代价是非常明显的——一次完整的TCP握手加挥手最快也要消耗一两个RTT在高并发场景下这个开销会被无限放大。更进一步说每一次连接的建立和销毁都会在操作系统层面留下一段TIME_WAIT状态连接高频率地建了又删端口资源会慢慢耗尽。连接池的思路其实和线程池类似提前创建一批连接放进池子里用的时候借出来用完还回去。把建立连接这个高频且昂贵的动作从每次请求里剥离开让它变成池子初始化时的一次性动作。Redisson的Redis TCP连接池正是干这件事的它把对Redis的所有读取和写入都放到池化的连接上执行减少握手开销同时借助池子限制并发连接数避免客户端把服务器连接数量顶爆。我之前在某个高并发抢券项目里最开始用的是每次请求新建连接的写法压测到两千QPS时监控上出现了大量TIME_WAIT服务端连接数也涨到了几千。后来整体切到Redisson连接池连接数稳定在几十服务端压力骤减。这就是连接池在当前场景里最直接的价值。1.2 Redisson和Jedis的连接管理逻辑差异很多人会把Redisson的连接池理解成JedisPool的翻版其实两者的底层机制完全不同。JedisPool是典型的使用方借还模式每个Jedis实例绑定一个物理Socket业务线程从池子里拿一个实例用完调用close归还。简单粗暴但问题在于池子内的连接对象和物理连接的生命周期完全绑定一旦网络抖动或者Redis主从切换连接失效需要重建JedisPool只能靠池内驱逐逻辑来处理。Redisson则不是这样。它底层的连接管理由Netty来做每个Redis连接被包装成Channel而Channel之上又有CommandService和连接池管理器。Redisson会把一个物理TCP连接切成逻辑上的并发命令通道多个业务请求可以复用同一个物理连接发送命令通过Promise关联各自的响应。这样设计的直接好处是连接数量不需要随并发线性增长——几百个并发操作共享一二十个连接也没问题而不是像Jedis那样一个并发要求一个连接。理解了上面这个差别就能明白为什么Redisson连接池参数通常比JedisPool里的maxTotal小很多依然能支撑很高的吞吐。同时也说明配置Redisson连接池时不能照搬Jedis那套调参经验需要从命令复用和物理连接健康两个维度重新考虑。2. Redisson连接池核心配置项逐个说清楚2.1 需要重点关注的一系列参数Redisson的配置对象或YAML里和TCP连接池直接相关的参数集中在几个位置。最常用的单机模式里重点是看connectionPoolSize、connectionMinimumIdleSize、timeout这几个如果部署在集群或哨兵模式还要额外关注每个Redis节点的连接池参数。connectionPoolSize是池子中允许的最大连接数这个参数决定了请求瞬间并发走Redis时的最大并行连接量。需要注意它并不是Redis客户端的并发上限因为Redisson会在一条物理连接上复用多路命令但也不能无脑调高每个连接都会占据服务端的一个文件描述符同时也会占用本地内存。connectionMinimumIdleSize是池子中保持的最小空闲连接数。设置这个值的目的在于当请求高峰期突然来临时不需要临时新建连接而是可以直接从池子里拿已经空闲的Channel。如果你能确定业务有比较规律的波峰和波谷把这个值设置为波谷时段的平均连接需求是比较合理的做法。timeout指的是从连接池中获取连接的等待时间单位是毫秒。当请求到达且池子内没有空闲连接同时连接数已经达到connectionPoolSize上限时新的请求会等待这个时间超时后抛出异常。这个值不宜设得太长否则会让调用线程长时间阻塞拖垮系统的整体响应但也不宜太短否则在瞬时流量尖峰时容易误伤正常请求。idleConnectionTimeout控制的是空闲连接被回收的时间。连接在池子里空闲超过该时间Redisson会主动关闭。这个参数要和Redis服务端的timeout配置一起看——如果服务端设置了空闲断开时间客户端的idleConnectionTimeout设置得比服务端长连接就会被服务端先断开而客户端还认为连接可用这就是常见的“偶发连接不可用”根因之一。pingConnectionInterval是心跳探测间隔Redisson会定期用PING命令检查池中连接的健康状态发现失效连接会主动剔除并重建。网络环境不稳定的情况下这个值可以适当调小更快感知断开的连接。以上这些参数的默认值和调优建议可以参考下表的整理。参数名默认值单机模式核心作用调优建议connectionPoolSize64最大活动连接数按并发量推算不要盲目加大connectionMinimumIdleSize10最小空闲连接数贴合低谷流量设置保证突发时够用timeout3000ms获取连接的超时时间不建议超过业务接口的SLAidleConnectionTimeout10000ms空闲连接回收时间必须小于服务端空闲断开时间pingConnectionInterval30000ms心跳探测健康状态网络抖动频繁时适当减小connectTimeout10000ms建立TCP连接的超时内网可调小跨机房要调大2.2 配置时最容易踩的隐性问题第一类容易踩的问题是连接池参数孤立地看没有结合整个Redis节点的连接数上限来考虑。很多云厂商的Redis实例默认最大连接数是10000但如果你部署了多个服务实例每个服务实例又注册了多个Redis连接加起来乘以节点数很快就会逼近服务端上限。这个不是Redisson本身的问题而是容量评估的问题但确实在配置连接池时最容易忽略。第二类问题是单机模式、主从模式、集群模式下连接池参数名称看起来很像作用却不一样。单机模式里connectionPoolSize管的是唯一一个节点的连接而集群模式里masterConnectionPoolSize和slaveConnectionPoolSize分别负责主节点和从节点。把集群模式里的读多写少业务配置成“主从连接池都调大”不仅浪费还会在主节点上形成无谓的连接压力。第三类问题是对timeout的误解。曾经有同事把timeout理解成“Redis命令执行超时”结果把它设成了50毫秒在Redis慢查询出现的瞬间大量线程都在限额上不必要地抛异常。实际上Redisson里命令本身的超时是另一个配置和连接池获取连接的等待时间要分开理解。连接池层面的timeout只负责控制“池子中拿不到连接时能等多久”。3. 不同部署模式下的连接池配置实战3.1 单机模式从YAML到编程式配置最典型的使用场景还是单机模式。一个Redis实例一个Redisson客户端配置最简洁。这里需要注意Redisson支持YAML、JSON、编程式三种方式多数项目里用YAML或编程式比较多。先看YAML配置方式这是一份可以直接用的最小配置singleServerConfig: address: redis://127.0.0.1:6379 password: null database: 0 connectionPoolSize: 64 connectionMinimumIdleSize: 10 connectTimeout: 10000 timeout: 3000 idleConnectionTimeout: 10000 pingConnectionInterval: 30000程序启动时通过Redisson的配置加载入口读取这份YAML就能得到一个具备默认连接池配置的RedissonClient。我在本地开发环境通常会把connectionPoolSize降到16把connectionMinimumIdleSize降到2因为开发环境的并发量根本用不到那么多连接减少连接占用也可以让本地IDE调试时减少Socket数量避免一些端口相关的困扰。如果偏好编程式配置可以这样写Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setConnectionPoolSize(64) .setConnectionMinimumIdleSize(10) .setConnectTimeout(10000) .setTimeout(3000) .setIdleConnectionTimeout(10000) .setPingConnectionInterval(30000); RedissonClient client Redisson.create(config);两种方式最终生效的参数一致选择哪种主要看团队习惯。不过有一个细节值得提醒如果你的配置中心是Apollo或Nacos想要动态修改连接池参数编程式配置会更容易实现因为可以在运行期重新构建Config并创建新的RedissonClient实例。YAML配置则通常需要重启应用才能生效。3.2 集群和哨兵模式下连接池参数怎么变单机模式切换到哨兵或集群模式后连接池参数的配置位置和粒度都会发生变化。先说哨兵模式Redisson的哨兵配置里有一个masterConnectionPoolSize和一个slaveConnectionPoolSize分别对应主节点和从节点的连接池大小同时也有各自的connectionMinimumIdleSize。哨兵模式下读写通常会分流读操作走从节点写操作走主节点。如果你的业务读多写少从节点的连接池可以适当调大主节点保持默认即可。集群模式比哨兵更复杂一点。Redisson针对每个集群主节点都会建立一个连接池配置项同样区分主从。集群里的每个master节点承载部分槽位的数据所以多个master节点之间的连接池配置会直接影响分片访问的并发能力。这里要特别提醒一点如果你的集群有3主3从那么masterConnectionPoolSize配置的是每一个主节点的连接池大小而不是全部主节点共享一个池子。也就是说3个主节点总共的连接上限是3乘以该配置值评估服务端连接数时要按照这个逻辑来算。来看一段集群模式配置示例clusterServersConfig: nodeAddresses: - redis://127.0.0.1:7000 - redis://127.0.0.1:7001 - redis://127.0.0.1:7002 masterConnectionPoolSize: 48 masterConnectionMinimumIdleSize: 8 slaveConnectionPoolSize: 48 slaveConnectionMinimumIdleSize: 8 timeout: 3000 idleConnectionTimeout: 10000 pingConnectionInterval: 30000很多人在集群模式下会犯的错误是把每个节点的池子都设得和单机模式一样大以为这样能提高吞吐。实际上在多分片集群里单节点连接数只需要达到一定规模就能打满该节点的CPU再往上加连接只会增加内存占用和服务端文件描述符消耗吞吐几乎没有变化。集群场景下更值得关注的是“槽位分布是否均匀”和“慢查询是否集中在某个节点上”连接池只是托底保障。4. 性能调优连接池到底要多大才合理4.1 推算连接池大小的思路连接池参数没有绝对的标准答案但可以通过一套简单推算来找到合理区间。核心思路是看两件事业务侧的请求QPS以及单次请求在Redis上平均耗时。假设一个接口每秒钟需要发起2000次Redis命令操作单次操作在Redis服务端的平均处理耗时是1毫秒那么同一时刻正在执行中的命令数量理论上是2000乘以0.001也就是2个并发。这个算出来的数字看起来很小但考虑到连接复用、命令排队、网络抖动等因素实际需要的连接数会比理论值稍高。常见的策略是把理论并发数乘以2到3倍作为连接池的基准值。再看真实场景。某个业务高峰期QPS是4000平均单次Redis命令耗时1.5毫秒那么理论并发就是4000乘以0.0015等于6个并发连接。把基准值放大到3倍得到18个连接。也就是说connectionPoolSize设置在20左右已经完全可以满足这个业务的吞吐需求再往上加连接并不会带来吞吐提升。我在实践中发现连接池参数的调节之所以难是因为瓶颈往往不在连接数本身而在于Redis单线程的处理能力。如果一个Redis实例的CPU已经打满连接池从50调到500也无法改善延迟。这时候优先要做的是定位慢查询、拆分大Key、把热点数据分层处理单纯调大连接池只会让请求在服务端排队时堆积更多。4.2 实测中看到的连接池性能拐点用压测数据说话会更直观。某次我对一个基于Redisson的服务做全链路压测配置从connectionPoolSize16开始逐步上调记录了对应的P99延迟和客户端错误数。连接数从16调到32时P99延迟明显下降错误率也降了。从32调到64时P99微微下降但收益已经很小。从64调到128时P99几乎不变错误率也没有变化而客户端的内存占用和服务端文件描述符数量却在上升。这说明在这个具体压力模型下连接池的合理区间在32到64之间超过64就是纯浪费。这个实验让我确认了一个观点——连接池并不是越大越好它只是在满足并发需求的前提下尽量保持最小的连接数量减少资源开销和问题暴露面。判断连接池是否合理不应该只看连接数还要关注P99延迟、错误率、服务端连接数这三个指标的组合。只要P99稳定、错误率为零连接池小一点反而是好事。另外提醒一句压测环境需要模拟真实的网络条件。如果压测客户端和Redis服务之间走的是本机回环网络RT会比真实环境低很多推算出的连接池大小也会偏小。跨机房或者云环境部署时RT通常会翻几倍连接池需要相应调整。5. 踩坑记录Redisson连接池的典型问题排查5.1 连接池耗尽Connection pool is exhausted这个异常应该是Redisson连接池最常见的报错报错信息里会明确提示连接池已满无法立即获取连接。第一次遇到时我下意识觉得是并发量太大直接把connectionPoolSize往上调结果发现治标不治本。后来排查才发现真正的问题出在服务端一个慢查询上——某个大Key的HGETALL操作耗时接近1秒大量请求在同一时间占住了连接后面的请求只能在池子里排队等。排查顺序可以按这个来先看Redis慢日志确认有没有单条耗时很长的命令再看服务端的connected_clients数值确认服务端实际连接数是不是达到上限最后再看客户端错误发生的时间段和业务高峰是否吻合。如果慢查询是偶发性的处理慢查询比调大连接池更有效如果确实是并发超高再考虑增加连接池大小或增加Redis节点分摊压力。另外还有一种隐蔽情况。业务代码里使用了Redisson的分布式锁或信号量但忘记在finally块中释放或者使用了RedissonClient获取RMap之后长期持有而不关闭也会导致连接无法归还。这类连接泄漏不会报错但会让连接池里的可用连接慢慢减少最终表现为偶发的连接池耗尽。排查时可以通过JMX或者框架自带的Metrics观察池内活跃连接数和空闲连接数的趋势。5.2 网络抖动导致的连接失效与重建Redisson底层虽然有Netty帮你管理和重建连接但网络环境的抖动还是会在某些瞬间暴露出来。最典型的现象是某一段时间内客户端日志没有任何异常但Redis服务端发现一批连接被断开紧接着Redisson客户端重新建连。这种问题的根源多半是idleConnectionTimeout和服务端timeout配置冲突。比如Redis服务端设置了timeout 300意味着空闲超过300秒的连接会被服务端断开而Redisson的idleConnectionTimeout默认是10000毫秒也就是10秒。这里看起来10秒远小于300秒不会触发问题。但如果有人把服务端timeout调成了5秒而Redisson的idleConnectionTimeout依然是10秒就会导致连接在客户端不知情的情况下被服务端断开。要避免这个问题建议把idleConnectionTimeout和Redis服务端的timeout对齐并且让前者比后者小20%到30%。同时pingConnectionInterval可以适当调低比如从默认的30秒调到10秒让客户端更频繁地确认连接健康状态一旦发现失效连接就及时剔除并重建避免业务线程用到坏连接。5.3 排查连接池问题的实用工具箱连接池问题排查起来光看日志是不够的还需要几个常规工具配合使用。Redis服务端执行INFO clients可以查看当前连接数、连接数上限、最近拒绝的连接数。CLIENT LIST可以列出所有客户端连接的详细信息包括连接的空闲时间、最后执行的命令方便判断哪些连接长时间空闲或异常占用。Redis的SLOWLOG GET可以随时查看最近执行的慢命令如果连接池耗尽前的某个时间点正好有慢命令基本就能锁定方向。客户端侧如果你的项目引入了Micrometer或者Spring Boot ActuatorRedisson会暴露一部分连接池指标比如连接数、空闲连接数、等待获取连接的线程数。这些指标可以接到监控系统里配合告警规则在连接池使用率超过阈值时提前预警而不是等到报错了才去查日志。还有一个容易被忽略的经验连接池相关的报错经常不是由Redisson自己抛出来的而是在业务调用分布式锁、读缓存、发消息时被包装成各种业务异常。排查时不要只看业务堆栈要往底层Redis操作那一行追溯通常能看到RedisConnectionException或者TimeoutException的影子顺着这个线索才能找到连接池层面的原因。6. 几个实用的经验值直接拿去用最后分享几个我在项目中沉淀下来的经验值。这些数字不是从文档里抄的是结合若干次压测和线上问题总结出来的可以作为你配置连接池时的起点。大多数内部系统的单机Redis服务connectionPoolSize设置在32到64之间就足够了如果只是本地开发或测试环境16就够用。connectionMinimumIdleSize设置为connectionPoolSize的四分之一到三分之一比较合适既能保证突发流量下有一定缓冲又不会让太多空闲连接白白占用资源。timeout按业务SLA来定内部接口一般2到3秒外部接口涉及Redis的部分最好别超过1秒。如果业务里大量使用Redisson的分布式锁获取锁的等待时间会导致线程在连接池上排队的时间变长此时connectionPoolSize需要在普通推算基础上上浮一些。但更推荐的做法是排查锁持有时间是否有优化空间而不是无限调大连接池。因为分布式锁本身是串行化资源连接池再大也不能让锁的并发能力提升。另外多环境部署时连接池参数不要复制粘贴。预发环境和生产环境的流量模型完全不同用相同的连接池配置要么预发浪费资源要么生产环境不够用。建议把连接池参数做成可配置项每个环境单独调整上线前用压测数据来验证而不是靠直觉。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
