共计 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 超时问题还有其他可能的问题会导致。
