记一次压测问题排查

这次我接收了一个活动项目，由于之前有个活动类型和我这个基本一致，所以直接copy的上一份活动。

上次活动为了提高并发能力，所以数据都存储在redis，等活动结束手动入mysql。

压测工具使用jemeter

线程数30，压100s，qps在300多

但是异常率很高

排查服务日志，疯狂刷一个错误：

lettuce连接异常：

Cannot assign requested address (Address not available) 

lettuce不是redis的一个新连接池吗？

于是chatgpt问答一番，得知springboot2.1之后redis默认使用lettuce连接池。

当时也没有在意redis配置，因为redis肯定是连接上了，很多请求正常返回了。

于是查看服务器TCP连接情况，一看我去30000多个TIME_WAIT，能用的端口基本用完。

百度了一番给服务扩了端口和TIME_WAIT复用，心想着这事就算解决了。

没想到再跑一次压测还是报错了，端口还是30000多个TIME_WAIT。

感觉不是端口的问题，治标不治本。

最后好几个同事一起看配置，发现我们的redis连接配置是生效的，但是redis连接池的配置是无效的！

spring.redis.pool.maxIdle=300

spring.redis.pool.minIdle=300

spring.redis.pool.max-wait=500

spring.redis.pool.max-active=1000

正确的配置应该是：

spring.redis.lettuce.pool.maxIdle=300

spring.redis.lettuce.pool.minIdle=300

spring.redis.lettuce.pool.max-wait=500

spring.redis.lettuce.pool.max-active=1000

为什么呢！因为springboot2.1之后，lettuce成了redis默认连接池，于是乎之前的jedis连接池配置就失效了，记一下这个坑希望能帮到更多的朋友，可能springboot-redis的开发觉得能用到高并发的肯定会优化这个参数，进而发现旧连接池的配置是无效的，好吧，竟然没有兼容老配置。

至于为什么lettuce默认的连接池配置顶不住高并发呢？这个就和连接池的策略有关系了，可能是因为连接池达到最大活跃后，后续的线程拿不到新的redis连接，且超过max-wait时间，所以抛出了异常。具体配置的解释如下：

spring.redis.lettuce.pool.maxIdle=300：这个属性指定了连接池中最大空闲连接数。在连接池中，当连接数超过这个值时，多出来的连接会被回收。

spring.redis.lettuce.pool.minIdle=300：该属性指定了连接池中最小空闲连接数。连接池会始终保持这么多的空闲连接数，确保有足够的连接可供使用。

spring.redis.lettuce.pool.max-wait=500：这个属性表示当连接池耗尽时，调用者最大阻塞的时间。如果超过了这个时间仍无法获取到连接，则会抛出异常。

spring.redis.lettuce.pool.max-active=1000：该属性表示连接池中最大的活动连接数。当连接池中的活动连接数达到这个值时，后续的连接获取将会阻塞，直到有连接被释放回连接池。