记一次redis 超时问题定位

2,579次阅读
没有评论

共计 824 个字符,预计需要花费 3 分钟才能阅读完成。

昨天开始线上的部分服务开始出现超时的现象,相比之前超时的比例高很多,应该是哪里出现问题了。看线上日志,主要出现在redis hgetall这块频繁的出现异常,找服务端同学定位到具体的 key,然后确定相应的redis cluster。

排查点1

redis 的整体 ops、net output 、命令数等数据统计基本上处于稳定的状态,命令数相比以前有一定的上升,但是可以接受范围。

排查点2

集群的有些机器处于下行状态

Redis集群通过分片的方式来保存数据库中的键值对,集群整个数据库被分为16384个槽(slot)的,数据库中的每个键都属于这16384个槽的其中一个,每个节点可以处理0个或者最多16384个槽。当数据库中的16384个槽都有节点在处理时,集群处于上线状态,如果任何一个槽没有得到处理,集群处于下行状态(fail)。

一个节点会将自己负责处理的槽记录在clusternode结构的slot属性和numlots属性中,同时将自己的slots数组通过消息发送给集群其他节点,以此告知其他节点自己负责处理哪些槽,举例:01,02,03 三个节点组成一个集群,槽0-5000分给01节点,槽5001-10000分给02节点,10001-16383分给03节点,对应的节点只处理自己负责的槽。收到命令时,如果键所在的槽正好是当前节点,就直接处理命令,否则想客户端返回一个moved错误,指引客户端转向正确的节点

排查点3

慢日志

发现集群上某台机器上面的执行超过40ms,后来DBA执行这台机器上实例的回收操作,然后服务报错的日志数量下降到正常值水平。出现问题的原因是之前这台机器宕机了,后来恢复之后,我们的集群比较大,恢复后获取集群的信息慢很多。

排查点4

客户端是否开启拓扑自动更新,虽然在排查点3中发现有些机器出现了问题,但是如果客户端拓扑更新打开自动获取最新也是可以解决问题

总结

以上是这次定位redis 超时的时候一些记录,redis 超时问题还有其他可能的问题会导致。

正文完
请博主喝杯咖啡吧!
post-qrcode
 
admin
版权声明:本站原创文章,由 admin 2022-02-08发表,共计824字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)
验证码