Springboot2.x集成lettuce连接redis集群报超时异常Command timed out after 6 second(s)

简介: 最近在对一新开发Springboot系统做压测,发现刚开始压测时,可以正常对redis集群进行数据存取,但是暂停几分钟后,接着继续用jmeter进行压测时,发现redis就开始突然疯狂爆出异常提示:Command timed out after 6 second(s)......

文/朱季谦

背景:最近在对一新开发Springboot系统做压测,发现刚开始压测时,可以正常对redis集群进行数据存取,但是暂停几分钟后,接着继续用jmeter进行压测时,发现redis就开始突然疯狂爆出异常提示:Command timed out after 6 second(s)......

 1 Caused by: io.lettuce.core.RedisCommandTimeoutException: Command timed out after 6 second(s)

 2     at io.lettuce.core.ExceptionFactory.createTimeoutException(ExceptionFactory.java:51)

 3     at io.lettuce.core.LettuceFutures.awaitOrCancel(LettuceFutures.java:114)

 4     at io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:123)

 5     at io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)

 6     at com.sun.proxy.$Proxy134.mget(Unknown Source)

 7     at org.springframework.data.redis.connection.lettuce.LettuceStringCommands.mGet(LettuceStringCommands.java:119)

 8     ... 15 common frames omitted

我急忙检查redis集群,发现集群里的各节点都一切正常,且cpu和内存使用率还不到百分之二十,看着这一切,我突然陷入漫长的沉思,到底是哪里出现问题......百度一番,发现不少人都出现过类似情况的,有人说把超时timeout设置更大一些就可以解决了。我按照这样的解决方法,把超时timeout的值设置到更大后,依然没有解决该超时问题。

其中,springboot操作redis的依赖包是——

 1 <dependency>

 2     <groupId>org.springframework.boot</groupId>

 3     <artifactId>spring-boot-starter-data-redis</artifactId>

 4 </dependency>

集群配置——

 1 redis:

 2   timeout: 6000ms

 3   cluster:

 4     nodes:

 5       - xxx.xxx.x.xxx:6379

 6       - xxx.xxx.x.xxx:6379

 7       - xxx.xxx.x.xxx:6379

 8   jedis:

 9     pool:

10       max-active: 1000

11       max-idle: 10

12       min-idle: 5

13       max-wait: -1

点进spring-boot-starter-data-redis进去,发现里面包含了lettuce的依赖:

看到一些网友说,springboot1.x默认使用的是jedis,到了Springboot2.x就默认使用了lettuce。我们可以简单验证一下,在redis驱动加载配置类里,输出一下RedisConnectionFactory信息:

 1 @Configuration

 2 @AutoConfigureAfter(RedisAutoConfiguration.class)

 3publicclass Configuration {

 4     @Bean

 5     public StringRedisTemplate redisTemplate(RedisConnectionFactory factory) {

 6         log.info("测试打印驱动类型:"+factory);

 7 }

打印输出——

测试打印驱动类型:org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory@74ee761e

可见,这里使用正是是lettuce驱动连接,目前我暂时的解决办法,是当把它换成以前用的比较多的jedis驱动连接时,就没有再出现这个Command timed out after 6 second(s)问题了。

 1 <dependency>

 2     <groupId>org.springframework.boot</groupId>

 3     <artifactId>spring-boot-starter-data-redis</artifactId>

 4     <exclusions>

 5         <exclusion>

 6             <groupId>io.lettuce</groupId>

 7             <artifactId>lettuce-core</artifactId>

 8         </exclusion>

 9     </exclusions>

10 </dependency>

11 <dependency>

12     <groupId>redis.clients</groupId>

13     <artifactId>jedis</artifactId>

14 </dependency>

那么问题来了,Springboot2.x是如何默认使用了lettuce,这得去研究下里面的部分代码。我们可以可进入到Springboot2.x自动装配模块的redis部分,其中有一个RedisAutoConfiguration类,其主要作用是对Springboot自动配置连接redis类:

 1 @Configuration(

 2     proxyBeanMethods = false

 3 )

 4 @ConditionalOnClass({RedisOperations.class})

 5 @EnableConfigurationProperties({RedisProperties.class})

 6 @Import({LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class})

 7publicclass RedisAutoConfiguration {

 8     public RedisAutoConfiguration() {

 9    }

10    ......省略

11 }

这里只需要关注里面的一行注解:

 1

 2 @Import({LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class})

 3

这就意味着使用spring-boot-starter-data-redis依赖时,可自动导入lettuce和jedis两种驱动,按理来说,不会同时存在两种驱动,这样没有太大意义,因此,这里的先后顺序就很重要了,为什么这么说呢?

分别进入到LettuceConnectionConfiguration.class与JedisConnectionConfiguration.class当中,各自展示本文需要涉及到的核心代码:

 1//LettuceConnectionConfiguration

 2 @ConditionalOnClass({RedisClient.class})

 3class LettuceConnectionConfiguration extends RedisConnectionConfiguration {

 4    ......省略

 5     @Bean

 6     @ConditionalOnMissingBean({RedisConnectionFactory.class})

 7     LettuceConnectionFactory redisConnectionFactory(ObjectProvider<LettuceClientConfigurationBuilderCustomizer> builderCustomizers, ClientResources clientResources) throws UnknownHostException {

 8         LettuceClientConfiguration clientConfig = this.getLettuceClientConfiguration(builderCustomizers, clientResources, this.getProperties().getLettuce().getPool());

 9         returnthis.createLettuceConnectionFactory(clientConfig);

10    }

11 }

12//JedisConnectionConfiguration

13 @ConditionalOnClass({GenericObjectPool.class, JedisConnection.class, Jedis.class})

14class JedisConnectionConfiguration extends RedisConnectionConfiguration {

15    ......省略

16     @Bean

17     @ConditionalOnMissingBean({RedisConnectionFactory.class})

18     JedisConnectionFactory redisConnectionFactory(ObjectProvider<JedisClientConfigurationBuilderCustomizer> builderCustomizers) throws UnknownHostException {

19         returnthis.createJedisConnectionFactory(builderCustomizers);

20    }

21 }

22

可见,LettuceConnectionConfiguration.class与JedisConnectionConfiguration.class当中都有一个相同的注解 @ConditionalOnMissingBean({RedisConnectionFactory.class}),这是说,假如RedisConnectionFactory这个bean已经被注册到容器里,那么与它相似的其他Bean就不会再被加载注册,简单点说,对LettuceConnectionConfiguration与JedisConnectionConfiguration各自加上 @ConditionalOnMissingBean({RedisConnectionFactory.class})注解,两者当中只能加载注册其中一个到容器里,另外一个就不会再进行加载注册。

那么,问题就来了,谁会先被注册呢?

这就回到了上面提到的一句,@Import({LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class})这一句里的先后顺序很关键,LettuceConnectionConfiguration在前面,就意味着,LettuceConnectionConfiguration将会被注册。

可见,Springboot默认是使用lettuce来连接redis的。

当我们引入spring-boot-starter-data-redis依赖包时,其实就相当于引入lettuce包,这时就会使用lettuce驱动,若不想使用该默认的lettuce驱动,直接将lettuce依赖排除即可。

 1 <dependency>

 2     <groupId>org.springframework.boot</groupId>

 3     <artifactId>spring-boot-starter-data-redis</artifactId>

 4     <exclusions>

 5         <exclusion>

 6             <groupId>io.lettuce</groupId>

 7             <artifactId>lettuce-core</artifactId>

 8         </exclusion>

 9     </exclusions>

10 </dependency>

然后再引入jedis依赖——

 1 <dependency>

 2     <groupId>redis.clients</groupId>

 3     <artifactId>jedis</artifactId>

 4 </dependency>

这样,在进行RedisAutoConfiguration的导入注解时,因为没有找到lettuce依赖,故而这注解@Import({LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class})的第二个位置上的JedisConnectionConfiguration就有效了,就可以被注册到容器了,当做springboot操作redis的驱动。

lettuce与jedis两者有什么区别呢?

lettuce:底层是用netty实现,线程安全,默认只有一个实例。

jedis:可直连redis服务端,配合连接池使用,可增加物理连接。

根据异常提示找到出现错误的方法,在下列代码里的LettuceConverters.toBoolean(this.getConnection().zadd(key, score, value))——

 1public Boolean zAdd(byte[] key, double score, byte[] value) {

 2     Assert.notNull(key, "Key must not be null!");

 3     Assert.notNull(value, "Value must not be null!");

 4

 5     try {

 6         if (this.isPipelined()) {

 7             this.pipeline(this.connection.newLettuceResult(this.getAsyncConnection().zadd(key, score, value), LettuceConverters.longToBoolean()));

 8             returnnull;

 9        } elseif (this.isQueueing()) {

10             this.transaction(this.connection.newLettuceResult(this.getAsyncConnection().zadd(key, score, value), LettuceConverters.longToBoolean()));

11             returnnull;

12        } else {

13             return LettuceConverters.toBoolean(this.getConnection().zadd(key, score, value));

14        }

15    } catch (Exception var6) {

16         throwthis.convertLettuceAccessException(var6);

17    }

18 }

LettuceConverters.toBoolean()是将long转为Boolean,正常情况下,this.getConnection().zadd(key, score, value)如果新增成功话,那么返回1,这样LettuceConverters.toBoolean(1)得到的是true,反之,如果新增失败,则返回0,即LettuceConverters.toBoolean(0),还有第三种情况,就是这个this.getConnection().zadd(key, score, value)方法出现异常,什么情况下会出现异常呢?

应该是,connection连接失败的时候。

这就意味着,以lettuce驱动连接redis的过程当中,会出现连接断开的情况,导致无法新增成功,超过一定时间还没有正常,就会出现连接超时的情况。

至于是什么原因导致的断开连接,暂时还没有比较好思路,暂且把这个问题留着,等慢慢研究看是否能找到问题所在,若有大神指点,也感激不尽。

 

最后发现,阿里云官网上关于redis的客户端连接,是不推荐使用Lettuce客户端——


目录
相关文章
|
7月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
510 2
|
5月前
|
NoSQL 算法 Redis
【Docker】(3)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!
Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
697 6
|
11月前
|
存储 NoSQL 数据库
Redis 逻辑数据库与集群模式详解
Redis 是高性能内存键值数据库,广泛用于缓存与实时数据处理。本文深入解析 Redis 逻辑数据库与集群模式:逻辑数据库提供16个独立存储空间,适合小规模隔离;集群模式通过分布式架构支持高并发和大数据量,但仅支持 database 0。文章对比两者特性,讲解配置与实践注意事项,并探讨持久化及性能优化策略,助你根据需求选择最佳方案。
530 5
|
6月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
8月前
|
负载均衡 NoSQL Redis
【赵渝强老师】Redis的主从复制集群
Redis主从复制是指将一台Redis服务器的数据复制到其他Redis服务器,实现数据热备份、故障恢复、负载均衡及高可用架构的基础。主节点负责写操作,从节点同步数据并可提供读服务,提升并发处理能力。
243 5
|
7月前
|
存储 NoSQL 算法
Redis的集群架构与使用经验
本文介绍了Redis的集群架构与使用经验,包括主从复制、哨兵集群及Cluster分片集群的应用场景与实现原理。内容涵盖Redis主从同步机制、数据分片存储方式、事务支持及与Memcached的区别,并讨论了Redis内存用尽时的处理策略。适用于了解Redis高可用与性能优化方案。
|
监控 NoSQL Redis
看完这篇就能弄懂Redis的集群的原理了
看完这篇就能弄懂Redis的集群的原理了
787 0
|
11月前
|
存储 NoSQL Redis
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构
|
存储 NoSQL 算法
Redis分片集群中数据是怎么存储和读取的 ?
Redis集群采用的算法是哈希槽分区算法。Redis集群中有16384个哈希槽(槽的范围是 0 -16383,哈希槽),将不同的哈希槽分布在不同的Redis节点上面进行管理,也就是说每个Redis节点只负责一部分的哈希槽。在对数据进行操作的时候,集群会对使用CRC16算法对key进行计算并对16384取模(slot = CRC16(key)%16383),得到的结果就是 Key-Value 所放入的槽,通过这个值,去找到对应的槽所对应的Redis节点,然后直接到这个对应的节点上进行存取操作
|
缓存 NoSQL Redis
Redis原理—3.复制、哨兵和集群
详细介绍了Redis的复制原理、哨兵原理和集群原理。

热门文章

最新文章