1. Lettuce连接池基础配置实战SpringBoot项目中使用Redis时Lettuce作为默认客户端早已成为开发者首选。但很多人可能不知道Lettuce在底层默默做了不少优化工作。先来看个真实案例去年我们电商系统在大促时突然出现Redis响应变慢最后发现是连接池配置不当导致的。下面我就把踩坑经验总结成可复用的配置方案。连接池的核心参数就像汽车的发动机参数调得好能让性能飙升。这几个参数你必须掌握max-active最大连接数相当于高速路的车道数。我们线上环境设置为200但要根据实际业务压力测试调整。设置太小会导致等待超时太大又会浪费资源。min-idle最小空闲连接数相当于常备的应急车道。建议设置为max-active的1/5我们生产环境用40。max-wait获取连接最长等待时间毫秒。这个参数特别关键设置太短会导致突发流量时大量请求失败太长又会拖慢系统。我们最终设定为300ms。具体配置代码示例Bean public LettuceConnectionFactory lettuceConnectionFactory() { GenericObjectPoolConfig poolConfig new GenericObjectPoolConfig(); poolConfig.setMaxTotal(200); poolConfig.setMinIdle(40); poolConfig.setMaxWaitMillis(300); poolConfig.setTimeBetweenEvictionRunsMillis(60000); // 检查空闲连接间隔 LettuceClientConfiguration clientConfig LettucePoolingClientConfiguration.builder() .poolConfig(poolConfig) .commandTimeout(Duration.ofMillis(500)) .build(); RedisStandaloneConfiguration config new RedisStandaloneConfiguration(redis-host, 6379); LettuceConnectionFactory factory new LettuceConnectionFactory(config, clientConfig); factory.setShareNativeConnection(false); // 关键配置 return factory; }这里有个特别容易踩的坑time-between-eviction-runs-millis参数。它控制连接池回收空闲连接的频率默认-1表示不回收。我们曾经因为这个没设置导致连接泄漏把Redis拖垮。现在建议设置为30-60秒配合min-evictable-idle-time-millis使用。2. 共享连接与连接池的相爱相杀Lettuce有个默认开启的隐藏技能——shareNativeConnection。这个属性默认为true时会让所有RedisTemplate共用一个物理连接。听起来很美好对吧但在连接池场景下这反而会成为性能杀手。通过源码分析可以看到当shareNativeConnectiontrue时LettuceConnectionFactory会创建SharedConnection实例所有获取连接的请求都指向同一个StatefulRedisConnection连接池配置实际上被绕过因为每次拿到的都是同一个连接这就好比去游泳馆办卡明明买了10次卡结果管理员每次都给你同一把更衣柜钥匙。我们曾经在压测时发现无论怎么调整连接池参数QPS都上不去最后发现是这个属性在作祟。解决方案很简单但容易忽略factory.setShareNativeConnection(false); // 必须显式关闭关闭后效果立竿见影连接池配置开始生效每个RedisTemplate操作都会从池中获取独立连接最大连接数限制真正起作用但要注意关闭共享连接后会稍微增加些内存开销因为要维护更多连接对象。我们在生产环境实测开启连接池关闭共享连接QPS提升了3倍左右。3. 高并发场景下的参数调优当你的系统面临秒杀级别的流量时连接池配置就变得尤为关键。去年双十一我们通过以下几组参数调整硬是把Redis的吞吐量提升了5倍连接管理参数test-on-borrow: true (借出连接时校验)test-while-idle: true (定期校验空闲连接)numTestsPerEvictionRun: 10 (每次检查连接数)超时控制参数connection-timeout: 200ms (TCP连接超时)so-timeout: 150ms (读写超时)shutdown-timeout: 100ms (优雅关闭等待)集群环境特别配置ClusterTopologyRefreshOptions refreshOptions ClusterTopologyRefreshOptions.builder() .enablePeriodicRefresh(Duration.ofMinutes(5)) // 定时刷新 .enableAdaptiveRefreshTrigger(RefreshTrigger.MOVED_REDIRECT) // 自适应刷新 .build(); ClusterClientOptions options ClusterClientOptions.builder() .topologyRefreshOptions(refreshOptions) .autoReconnect(true) .build();实际压测数据对比单节点Redis 5.08核16G配置方案QPS平均延迟错误率默认配置12k85ms1.2%优化配置58k22ms0.01%特别提醒在Kubernetes环境中还需要配置TCP keepalive避免网络闪断SocketOptions socketOptions SocketOptions.builder() .keepAlive(SocketOptions.KeepAliveOptions.builder() .enable(true) .idle(Duration.ofSeconds(30)) .build()) .build();4. 生产环境问题排查指南连接池用得好不如用得稳下面分享几个实战中遇到的典型问题案例1连接泄漏症状Redis连接数持续增长直到超过限制 排查步骤使用redis-cli client list查看空闲连接检查代码中是否有未关闭的RedisTemplate操作配置连接泄露检测poolConfig.setRemoveAbandonedOnBorrow(true); poolConfig.setRemoveAbandonedTimeout(180); // 3分钟案例2突发超时症状平时运行正常流量突增时大量超时 解决方案调整max-wait为更合理的值我们设置为300ms增加快速失败逻辑Bean public RedisTemplateString, Object redisTemplate() { RedisTemplateString, Object template new RedisTemplate(); template.setEnableTransactionSupport(false); // 非事务模式更快 // ...其他配置 }案例3集群拓扑刷新不及时症状集群节点变更后出现MOVED错误 优化方案ClusterTopologyRefreshOptions.builder() .enableAllAdaptiveRefreshTriggers() // 开启所有自适应触发 .adaptiveRefreshTriggersTimeout(Duration.ofSeconds(30)) // 超时控制 .build();最后给个实用小技巧在Spring Actuator中添加健康检查Bean public RedisHealthIndicator redisHealthIndicator(RedisConnectionFactory factory) { return new RedisHealthIndicator(factory); }这样就能通过/actuator/health实时监控Redis连接状态。记住好的连接池配置不是一蹴而就的需要结合监控数据持续调优。我们现在的做法是每周review一次Redis监控指标根据实际负载动态调整参数。
