Redis big key过期导致应用超时

突然收到告警,提示redis挂了,同时大群也在说某某redis连接超时了,过了一会儿就恢复了。这时登上服务器,查看监控。首先看看qps:

可以看到qps并不高,但是中间有段时间没取到数据是怎么回事?那么继续看看redis的cpu使用率:

可以看到cpu已经饱和,这也就能解释为何断图了,因为redis是单线程,在使用cpu 100%以后,就无法处理其他的命令了,zabbix也就无法执行info命令取qps了。那么已经知道是cpu使用饱和造成的问题,那么到底是什么原因呢?那么继续查看,cpu使用高的这段时间有没有慢日志:

好像也不是导致cpu高的凶手,这就难排查了,这个实例是1主1从。那么我看看从库的cpu使用情况看看:

卧槽,怎么回事,从库没有使用的怎么cpu也用到了74%?这不科学啊?管他的,看看从库有没有慢日志:

卧槽,怎么回事?从库没人使用啊。看看是否只读:

127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103> 

看来是只读的,这把我给整懵了。最后突然想到是主库在这个点有big key过期,而主库过期key操作慢是不会记录慢日志的,从库的key过期是由主库发起DEL指令删除的。这时从库就会记录慢日志,从上面慢日志可以看到这些DEL操作最大的335ms,怪不得会有应用连接超时的。

总结:

redis由于的单线程,单个耗时过大命令,导致阻塞其他命令。key尽量的控制大小。那么key的过期最好是手动写脚本删除,比如删除大set键,使用sscan命令,每次扫描集合中500个元素,再用srem命令每次删除一个键。当然还可以合理的设置过期时间,设置过期时间不在业务的高峰期,业务高峰期一般每天都在同一时间,那么过期时间设置整数天+8个小时左右就是凌晨了,就避免了在业务高峰期过期。

时间: 2024-10-08 11:53:12

Redis big key过期导致应用超时的相关文章

redis中key过期事件

刚到新公司一个月左右,有个新需求,想做定时任务,比如在用户注册时间的3天后推送用户一条消息. 从刚开始脑子里面闪现的数据库轮询,立马否定掉(浪费资源),再到linux系统的定时任务,但是当用户量过大时,肯定不行. 最后想着redis如果key过期了,能不能监听触发一个事件,这样便可以不用时刻的查询是否到了发送消息的时间,从而节省资源. 最终找到了 redis的key过期事件.通过监听redis的过期时间,在过期时触发一个事件,从而通过这个事件做其他事情. 操作步骤(liunx系统): 1.找到r

Redis的key过期处理策略

Redis中有三种处理策略:定时删除.惰性删除和定期删除. 定时删除:在设置键的过期时间的时候创建一个定时器,当过期时间到的时候立马执行删除操作.不过这种处理方式是即时的,不管这个时间内有多少过期键,不管服务器现在的运行状况,都会立马执行,所以对CPU不是很友好. 惰性删除:惰性删除策略不会在键过期的时候立马删除,而是当外部指令获取这个键的时候才会主动删除.处理过程为:接收get执行.判断是否过期(这里按过期判断).执行删除操作.返回nil(空). 定期删除:定期删除是设置一个时间间隔,每个时间

redis的key过期时间

public void set(String key,String value,int liveTime){ this.set(key, value); this.getJedis().expire(key, liveTime); } 通过设置key的淘汰时间来决定key的存储策略

由delete导致的超时已过期问题

1. 问题 开发人员反映应用程序中一条简单的delete语句执行报“超时已过期”错误.delete语句形式如下: delete * from table_1 where [email protected] 2. 分析 1)验证delete检索字段是否有索引 首先我想到的是检索字段 id 列上是否有索引,即是否能很快找到这条待删除的语句. 查看表的索引列表后,发现id上是存在索引的,而且是聚集索引. 单独执行 select * from table_1 where [email protected

Redis Sentinel环境下的Key过期事件消息订阅

一.Redis Sentinel Sentinel是Redis 2.8之后官方发布的HA解决方案,通过Sentinel可以保障整个Redis系统的高可用性.当Redis系统中的Master在异常情况下停止服务后,若干Sentinel会及时察觉并主观判断Master down(Subjectively Down),并且随后由一定数量的Sentinel共同确定Master确实客观已down(Objectively Down),这个时候Sentinel们会选举出一个新的Master继续提供服务.Red

redis 下key的过期时间详解 :expire

Redis是一个开源的Key-Value数据缓存,和Memcached类似. Redis多种类型的value,包括string(字符串).list(链表).set(集合).zset(sorted set --有序集合)和hash(哈希类型). Jedis 是 Redis 官方首选的 Java 客户端开发包. redis通过expire命令来设置key的过期时间. 语法:redis.expire(key, expiration) 1. 在小于2.1.3的redis版本里,只能对key设置一次exp

Redis中Key相关的常用指令详解

Redis是一个开源的使用ANSI C 语言编写.支持网络.同memcache相比在Redis下可以实现基于内存亦可持久化的日志型.Key-Value 类型的NoSQL数据库,且在Redis中Key的类型也更为丰富.所以较为广泛的在生产环境中使用,在这里就说一说Redis中Key相关的常用指令. 首先,先要说明下在Redis下Key,Redis的key是字符串类型,但是key 中不能包括边界字符(""),由于key 不是binary safe的字符串,所以像"my key&q

【故障处理141119】一次数据库不繁忙时一条sql语句2个运行计划导致业务超时的故障处理

1,故障描写叙述: 一条select有两个运行计划.在sqlplus中运行选择好的运行计划.仅仅要40毫秒.而在程序中运行选择了差的运行计划,要1分23秒左右,导致前台业务超时报错. 2.故障解决: 使用outline固定好的运行计划后攻克了该故障. 3,故障发展顺序: (1),早上一上班,说CRM的一个业务报错,crm应用开发者.接口的.tuxdo.dba集中到一起開始诊断错误. (2),业务返回超时错误 (3),数据库这边抓取AWR报告发现例如以下信息: (4),此时应用开发者也发过来了该条

Redis 键(key) 讲解 - Redis 教程

Redis 键命令用于管理 redis 的键. 语法 Redis 键命令的基本语法如下: redis 127.0.0.1:6379> COMMAND KEY_NAME 实例 redis 127.0.0.1:6379> SET w3ckey redis OK redis 127.0.0.1:6379> DEL w3ckey (integer) 1 在以上实例中 DEL 是一个命令, w3ckey 是一个键. 如果键被删除成功,命令执行后输出 (integer) 1,否则将输出 (integ