Redis EXISTS命令耗时过长case排查
2016-01-19 16:47
651 查看
一、背景
redis慢日志分析平台上线后,随便看了一下,发现onestore使用的缓存集群,存在大量的EXISTS命令慢查询的情况:平均每个EXISTS命令需要13ms,最大耗时近20ms。这个结果很不科学啊,EXISTS命令只是执行一次hash查找操作,应该是us级别。 和相关同学了解业务背景如下: - 业务是userfeed,存放用户发表的动态 - 使用zset存储一个用户发表的所有动态,key是用户id,集合中对应的是feedid。如果用户发表的动态很多,zset也很大 - redis集群作为onestore的缓存,过期时间是10分钟 - 在访问cache前会调用EXISTS查看是否命中,如果不命中就用onestore回填cache 由于一些用户发表的动态很多(2W+),所以存在很多的ZADD慢查询。
二、排查
1. redis的清除过期key的策略- 被动方式:在事件循环中,每秒执行约10次,尽力删除过期的key,会有漏掉的情况- 从expire set中随机检查20个key- 删除到过期的key- 如果超过25%的key都是过期了,就重复第一步(超过25%说明过期的key占比很多)- 主动方式:- 如果该key在被动方式中漏过,在其再次被访问时检查并清除2. 查看代码void existsCommand(redisClient *c) { expireIfNeeded(c->db,c->argv[1]); // 检查该key是否过期,如果过期就delete掉 if (dbExists(c->db,c->argv[1])) { addReply(c, shared.cone); } else { addReply(c, shared.czero); } }在EXISTS命令处理函数中实现了清除过期key的主动策略,会先调用expireIfNeeded函数检查要访问的key是否过期,如果过期就delete掉这个key。del命令在删除元素很多的复合数据类型(list、hash、zset、set)时是一个很耗时的操作。由于存在元素很多的zset,和ZADD一样,在删除zset时需要一个一个遍历所有元素,时间复杂度是大O(n)。由于这个删除操作在EXISTS命令的处理函数中执行,所以导致EXISTS耗时过长。
3. redis慢日志验证
通过慢日志可以验证上述结论
- EXISTS先检查‘user:94479529:feed’是否存在,该key已经过期,触发主动过期机制,将该key删除 - 从onestore获取该key的数据,然后通过ZADD回填
三、风险
该集群单个实例qps达到8k+,同时每天有10W+的慢查询。在redis存在大量慢查询时,会存在个别客户端超时的情况,导致请求失败。四、后续处理
1. 增加过期时间,由10分钟到20分钟 2. 对redis集群扩容(试增加过期时间的效果而定) 对于redis删除大key耗时的问题,redis作者提供了解决方案,具体就是使用异步线程对大key进行删除操作,避免阻塞主线程。相关文章推荐
- [转]阿里云 Linux 安装phpredis扩展 How to install Redis and Redis php client
- Redis简介
- Redis 管道技术
- Redis学习记录之persistence简析(二十五)
- redis使用小结
- redis常见操作命令-sortedset
- 《Redis系列专题》 之 大规模互联网应用Redis架构要点(精华)
- Redis常用命令记录
- redis数据迁移
- Redis学习记录之protocol简析(二十四)
- Redis的连接
- 基于redis缓存的session共享
- redis之如何配置jedisPool参数
- Redis 列表(List)
- redis集群操作
- redis队列及多线程应用
- Redis安装部署(Linux)
- Redis系列二:Redis支持的数据类型和使用方法(一)
- Redis系列三:Redis常用设置
- Redis系列一:初识Redis