Redis超时排查的示例分析

大家好，我们又见面了啊~本文《Redis超时排查的示例分析》的内容中将会涉及到等等。如果你正在学习数据库相关知识，欢迎关注我，以后会给大家带来更多数据库相关文章，希望我们能一起进步！下面就开始本文的正式内容~

前两天的工作中，突然收到告警，提示 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，怪不得会有应用连接超时的。

再使用命令 info commandstats 看看：

 

今天带大家了解了的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~