记录redis集群连接超时问题及解决方案

原创 已于 2023-09-20 17:05:01 修改 · 2.1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #bootstrap #数据库 #缓存 #前端

于 2022-09-15 16:55:00 首次发布
在一项业务场景的性能测试中，遇到Redis命令超时的问题，日志显示由于RedisCommandTimeoutException，具体是1分钟内未收到响应。进一步排查发现，6692端口的Redis节点因内存达到4.9G，100%占用率而挂掉。6691和6693节点虽然内存占用率也接近100%，但实际使用不超过300M，内存未在集群内均衡分配。为解决超时问题，临时清除了相关节点的缓存。建议检查redis.conf配置文件，设定maxmemory为4G，并重启集群，以实现内存均衡并预防服务挂掉。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

下午同事反馈，某业务场景性能测试过程中，出现异常，提供日志报： Redis command timed out

1. 先看下日志

org.springframework.dao.QueryTimeoutException: Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after 1 minute(s)
    at org.springframework.data.redis.connection.lettuce.LettuceExceptionConverter.convert(LettuceExceptionConverter.java:70) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceExceptionConverter.convert(LettuceExceptionConverter.java:41) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.PassThroughExceptionTranslationStrategy.translate(PassThroughExceptionTranslationStrategy.java:44) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.FallbackExceptionTranslationStrategy.translate(FallbackExceptionTranslationStrategy.java:42) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceConnection.convertLettuceAccessException(LettuceConnection.java:271) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceConnection.await(LettuceConnection.java:1062) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceConnection.lambda$doInvoke$4(LettuceConnection.java:919) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceInvoker$Synchronizer.invoke(LettuceInvoker.java:665) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceInvoker.just(LettuceInvoker.java:94) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.lettuce.LettuceSetCommands.sMembers(LettuceSetCommands.java:149) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.connection.DefaultedRedisConnection.sMembers(DefaultedRedisConnection.java:805) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.core.DefaultSetOperations.lambda$members$10(DefaultSetOperations.java:214) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:222) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:189) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.core.AbstractOperations.execute(AbstractOperations.java:96) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.core.DefaultSetOperations.members(DefaultSetOperations.java:214) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.data.redis.core.DefaultBoundSetOperations.members(DefaultBoundSetOperations.java:152) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    at org.springframework.session.data.redis.RedisSessionExpirationPolicy.cleanExpiredSessions(RedisSessionExpirationPolicy.java:132) ~[spring-session-data-redis-2.5.6.jar!/:2.5.6]
    at org.springframework.session.data.redis.RedisIndexedSessionRepository.cleanupExpiredSessions(RedisIndexedSessionRepository.java:424) ~[spring-session-data-redis-2.5.6.jar!/:2.5.6]
    at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54) ~[spring-context-5.3.20.jar!/:5.3.20]
    at org.springframework.scheduling.concurrent.ReschedulingRunnable.run(ReschedulingRunnable.java:95) [spring-context-5.3.20.jar!/:5.3.20]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_191]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_191]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_191]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_191]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_191]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_191]
    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_191]
Caused by: io.lettuce.core.RedisCommandTimeoutException: Command timed out after 1 minute(s)
    at io.lettuce.core.internal.ExceptionFactory.createTimeoutException(ExceptionFactory.java:59) ~[lettuce-core-6.1.8.RELEASE.jar!/:6.1.8.RELEASE]
    at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:246) ~[lettuce-core-6.1.8.RELEASE.jar!/:6.1.8.RELEASE]
    at io.lettuce.core.LettuceFutures.awaitOrCancel(LettuceFutures.java:74) ~[lettuce-core-6.1.8.RELEASE.jar!/:6.1.8.RELEASE]
    at org.springframework.data.redis.connection.lettuce.LettuceConnection.await(LettuceConnection.java:1060) ~[spring-data-redis-2.5.11.jar!/:2.5.11]
    ... 22 common frames omitted

2022-09-15 15:31:00.427  INFO 16828 --- [xecutorLoop-1-3] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:31:00.427  INFO 16828 --- [xecutorLoop-1-2] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:31:00.428  WARN 16828 --- [ioEventLoop-8-4] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692
2022-09-15 15:31:00.429  WARN 16828 --- [ioEventLoop-8-5] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692
2022-09-15 15:31:00.606  INFO 16828 --- [xecutorLoop-4-7] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:31:00.608  WARN 16828 --- [ioEventLoop-9-3] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692
2022-09-15 15:31:30.527  INFO 16828 --- [xecutorLoop-1-6] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:31:30.527  INFO 16828 --- [xecutorLoop-1-7] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:31:30.530  WARN 16828 --- [ioEventLoop-8-7] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692
2022-09-15 15:31:30.532  WARN 16828 --- [ioEventLoop-8-6] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692
2022-09-15 15:31:30.706  INFO 16828 --- [xecutorLoop-4-8] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:31:30.714  WARN 16828 --- [ioEventLoop-9-4] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692
2022-09-15 15:32:00.627  INFO 16828 --- [xecutorLoop-1-2] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692
2022-09-15 15:32:00.627  INFO 16828 --- [xecutorLoop-1-4] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 192.168.0.163:6692

从日志可以看出：Cannot reconnect to [192.168.0.163:6692]: Connection refused: /192.168.0.163:6692

*********************************************************************************************************************************************************************************************

2. 登入redis集群服务器看下redis服务状态

[root@iZ2ze0gm3scdypc0i15r8yZ redis-cluster]# ps -ef|grep redis
root      1718     1 78 09:36 ?        04:49:50 ./redis-server *:6695 [cluster]
root      1723     1 36 09:36 ?        02:12:52 ./redis-server *:6693 [cluster]
root      1724     1 94 09:36 ?        05:49:34 ./redis-server *:6694 [cluster]
root      1726     1 94 09:36 ?        05:48:41 ./redis-server *:6696 [cluster]
root      1727     1 35 09:36 ?        02:12:15 ./redis-server *:6691 [cluster]
root      2426     1  0 09:48 ?        00:01:16 ./redis-server *:6379
root     22212 22111  0 15:44 pts/4    00:00:00 grep --color=auto redis

可以看出，6692端口的redis节点挂掉了。为什么会挂掉？

*********************************************************************************************************************************************************************************************

3. 先把6692端口对应的redis节点启动，看下内存

[root@iZ2ze0gm3scdypc0i15r8yZ redis-cluster]# ./redis-cli -h 192.168.0.163 -p 6692 -c -a Tiye@123!
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.0.163:6692> info memory
# Memory
used_memory:5255993312
used_memory_human:4.90G
used_memory_rss:6011609088
used_memory_rss_human:5.60G
used_memory_peak:5255993312
used_memory_peak_human:4.90G
used_memory_peak_perc:100.00%
used_memory_overhead:23434632
used_memory_startup:1483784
used_memory_dataset:5232558680
used_memory_dataset_perc:99.58%
allocator_allocated:5225666392
allocator_active:6178586624
allocator_resident:6227939328
total_system_memory:33020043264
total_system_memory_human:30.75G
used_memory_lua:32768
used_memory_lua_human:32.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.18
allocator_frag_bytes:952920232
allocator_rss_ratio:1.01
allocator_rss_bytes:49352704
rss_overhead_ratio:0.97
rss_overhead_bytes:-216330240
mem_fragmentation_ratio:1.15
mem_fragmentation_bytes:786011688
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:0
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

从6692节点的redis内存可看出，内存已达到最大值：4.9G，内存占用率为100%，这是该节点挂掉的原因。

*********************************************************************************************************************************************************************************************

4. 再来看看6691、6693两个节点的内存使用情况

[root@iZ2ze0gm3scdypc0i15r8yZ redis-cluster]# ./redis-cli -h 192.168.0.163 -p 6691 -c -a Tiye@123!
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.0.163:6691> info memory
# Memory
used_memory:312651792
used_memory_human:298.17M
used_memory_rss:317714432
used_memory_rss_human:303.00M
used_memory_peak:313941360
used_memory_peak_human:299.40M
used_memory_peak_perc:99.59%
used_memory_overhead:38853632
used_memory_startup:1483784
used_memory_dataset:273798160
used_memory_dataset_perc:87.99%
allocator_allocated:312643776
allocator_active:313520128
allocator_resident:322052096
total_system_memory:33020043264
total_system_memory_human:30.75G
used_memory_lua:32768
used_memory_lua_human:32.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.00
allocator_frag_bytes:876352
allocator_rss_ratio:1.03
allocator_rss_bytes:8531968
rss_overhead_ratio:0.99
rss_overhead_bytes:-4337664
mem_fragmentation_ratio:1.02
mem_fragmentation_bytes:5103624
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:841560
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

[root@iZ2ze0gm3scdypc0i15r8yZ redis-cluster]# ./redis-cli -h 192.168.0.163 -p 6693 -c -a Tiye@123!
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.0.163:6693> info memory
# Memory
used_memory:313492000
used_memory_human:298.97M
used_memory_rss:318951424
used_memory_rss_human:304.18M
used_memory_peak:314344552
used_memory_peak_human:299.78M
used_memory_peak_perc:99.73%
used_memory_overhead:38814608
used_memory_startup:1483784
used_memory_dataset:274677392
used_memory_dataset_perc:88.04%
allocator_allocated:313483968
allocator_active:314449920
allocator_resident:322850816
total_system_memory:33020043264
total_system_memory_human:30.75G
used_memory_lua:32768
used_memory_lua_human:32.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.00
allocator_frag_bytes:965952
allocator_rss_ratio:1.03
allocator_rss_bytes:8400896
rss_overhead_ratio:0.99
rss_overhead_bytes:-3899392
mem_fragmentation_ratio:1.02
mem_fragmentation_bytes:5500440
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:821056
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

6691、6693两个节点的redis内存占用率也达到了99%以上，但是实际使用内存不超过300M，redis内存在集群内没有做到均衡

*********************************************************************************************************************************************************************************************

5. redis超时问题解决办法

redis超时问题的解决办法：清除6691、6692、6693这三个主节点的缓存。不过，这只是个临时的解决方案。

[root@iZ2ze0gm3scdypc0i15r8yZ redis-cluster]# ./redis-cli -h 192.168.0.163 -p 6691 -c -a Tiye@123!
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.192.168.0.163:6691> flushall
OK

*********************************************************************************************************************************************************************************************

6. 目前问题及个人认为的最佳解决方案

6.1 目前存在问题

　　redis内存消耗没有在集群内部达到均衡。

6.2 个人认为的最佳解决方案

　　查看redis.conf配置文件，最大内存配置( redis.conf默认配置)为：# maxmemory <bytes>       

　　redis服务器总内存大小为32G，根据经验(之前在上海的某个项目，设置maxmemory为固定值，集群内部所有节点的内存消耗均衡)，可以给6个redis节点都分配4G内存。即： maxmemory 4096M

重启redis集群。

***************后续待观察，redis集群最大内存是否达到均衡，redis服务是否还会挂掉*************************

解决使用lettuce连接Redis超时的问题（tcpUserTimeout 参数失效问题）
qq_21047625的博客
05-07 1002
lettuce 连接Redis的主从实例，当主节的主机异常下电重启后，由于没有发送RST 包，导致 lettuce 一直在复用之前的TCP链接，然后会出现连接超时的情况。就可以不再等待15分钟。但是由于影响较大，也会影响主机上其他的TCP连接，此方案被排除。的错误，直到约15分钟后，TCP不再重传，断开连接才恢复。，应用日志显示参数不生效，同时验证后确实无效，问题依然存在。)，升级 lettuce 的依赖到 6.3.0，同时设置。应用启动不再提示，并且在故障后30s出现重连的日志，说明。
IDEA springboot 连接虚拟机docker搭建的redis集群连接超时问题 connection timed out: /172.172.0.4:6379
weixin_60584969的博客
11-30 2554
最开始以为是防火墙的原因，因为自己做了端口映射，但是把防火墙关闭后还是无法连接docker搭建的redis集群，希望有大佬可以讲解一下！我在电脑上面运行虚拟机，在虚拟机使用docker来搭建redis集群，在本地使用IDEA 创建springboot项目连接redis集群，在 set 时出现连接超时的情况。感觉这个ip有点怪，本地的IDEA直接访问的容器内部的ip，因为没有做路由，而且这个docker网段还是自己创建的用来给docker容器分配静态ip。配置好后，来ping一下，发现可以ping通。
课代表笔记之redis 大量连接超时排查
weixin_43276857的博客
11-06 839
故障排查经验总结
redis集群连接异常
qq_34526613的博客
07-18 503
链接redis集群发生异常，原因可能是linux的防火墙未关闭。
springboot连接redis集群超时（云服务器）
花落因为花开过的博客
04-02 750
我使用的xshell连接云服务器，使用ifconfig得到的ip就是10.0.4.4。此时springboot连接redis集群就不会报超时问题了。Springboot版本为2.7.6。redis pom.xml文件。properties配置。启动各个redis服务器。
Java调用Redis集群代码及问题解决
08-25
Java调用Redis集群代码及问题解决 Java调用Redis集群代码是Java开发中常见的一种场景，当我们需要使用Redis集群来存储和管理大量数据时，需要使用Java语言来调用Redis集群。下面我们将详细介绍Java调用Redis集群...
aliyun redis 链接超时_使用ECS自己搭建Redis集群出现JedisCluster连接超时的问题
weixin_39966941的博客
12-21 535
自己在阿里云的ECS(配置是1G ,1核)上搭建了一个redis集群(端口7000-7005)，在服务器上测试redis-cli -c -ip -p 7000执行set，get方法的时候能够正确的重定向slot(定向到公网ip+端口，创建的时候是用公网ip创建的)而且自己在电脑上的虚拟机上使用，和另外一台阿里云服务器redis-cli -c -h 我的公网ip -p 7000都能够正常访问，而且能...
Redis集群下过期key监听的实现代码
12-16
在使用redis集群时，发现过期key始终监听不到。网上也没有现成的解决方案。于是想，既然不能监听集群，那我可以建立多个redis连接，分别对每个redis的key过期进行监听。以上做法可能不尽人意，目前也没找到好的解决...
Redis如何实现分布式锁，单机Redis与集群Redis问题解决方案
睡竹的博客
04-02 1185
Redis如何实现分布式锁，单机Redis与集群Redis问题解决方案
Redis 集群实现方案详解
最新发布
07-07
这些文件共同构成了一个完整的Redis集群部署解决方案。 RedisClusterExample.java文件提供了使用Java语言实现Redis集群操作的代码示例。在这个文件中，开发者能够看到如何通过Java连接到Redis集群的各个节点，以及...
谷粒商城day18-分布式组件-SpringCloud Alibaba-Nacos配置中心简单示例
JavaCoder_juejue的博客
08-26 545
为什么要用到配置中心呢，是为了方便配置的管理，并且使得不用修改配置就要重启用到改配置的多个应用 初步的使用步骤如下 1.common内引入如下两个依赖 <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </depende..
redis读数据超时问题查询
TURING.DT
08-30 8973
一、Redis超时问题排查 客户端设置了超时时间为200ms, 应用端反馈超时情况，并提供的超时日志。 逐个排查： 1. Redis慢查询：并没有发现慢查询 2. Redis日志：没有什么异常，也没什么RDB和AOF重写 3. 机器：观察cpu，内存，网络，负载，本地IO都正常 4. 唯一以前怀疑的是网络，按理说这个流量也不是很大，进行简单分析。 redis-cli r
Springboot连接Redis超时问题解决
Xuhai0811的博客
08-31 2462
Lettuce是基于Netty框架的事件驱动的Redis客户端，其方法调用是异步的，Lettuce的API也是线程安全的，所以多个线程可以操作单个Lettuce连接来完成各种操作，同时Lettuce也支持连接池.Jedis是同步的，不支持异步，Jedis客户端实例不是线程安全的，需要每个线程一个Jedis实例，所以一般通过连接池来使用Jedis.# #连接池最大阻塞等待时间（使用负值表示没有限制）基于 Netty 框架的事件驱动的通信，可异步调用。# 连接池中的最小空闲连接。# 连接池中的最大空闲连接。
Redis安全加固策略：配置文件权限设置 & 配置本地日志存储目录 & 连接超时时间限制
热门推荐
✨ 欢迎来到【Seal ^_^ 的优快云博客】！✨
03-03 1万+
Redis安全加固策略：配置文件权限设置 & 配置本地日志存储目录 & 连接超时时间限制
redis 客户端超时时间
cszskkk1的博客
12-16 7515
/* Check for timeouts. Returns non-zero if the client was terminated.  * The function gets the current time in milliseconds as argument since  * it gets called multiple times in a loop, so calling g
Springboot，Redis连接超时，解决方案
普通人一枚
09-30 1953
Springboot，Redis连接超时，解决方案
SpringBoot整合Redis,连接超时及其解决方案
web18484626332的博客
04-27 2719
在Spring Boot中整合redis的步骤： 1.引入redis的starters org.springframework.boot spring-boot-starter-data-redis 2. 写配置类，注入名为redisTemplate的bean @Configuration public class RedisConfig { /** * 向容器注入名称为方法名的（redisTemplate）bean * @return */
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值