Redis集群节点出错了，怎么快速排查那些让人头疼的问题和技巧分享

前段时间，我们的Redis集群半夜报警，说是有节点连接不上，搞得大家都很紧张，这种问题说大不大，说小不小，但如果找不到头绪，真的能让人抓狂，根据我们这次处理的经验，还有平时看一些技术社区像掘金、知乎上一些高手的分享，我总结了一套比较实用的排查思路，不是什么高深的理论,就是一步步怎么做的过程。

第一步，先别慌，搞清楚到底哪个节点“病了”

报警邮件可能只说“集群异常”，但具体是哪个节点出问题，是什么问题，得我们自己看，这时候，第一件事就是登录到集群的任意一个还健康的节点上，执行一个命令：redis-cli cluster nodes（如果设置了密码，记得加上 -a 密码），这个命令会列出集群里所有节点的信息，包括节点ID、IP地址、端口、角色（是主节点还是从节点）、以及节点之间的连接状态。

你重点看两个地方：一个是节点的“角色”，看看是不是有主节点掉线了，或者它的从节点跟它失联了，另一个是每个节点最后面的那个“状态”字段，connected 表示正常连接，fail 表示可能出问题了，handshake 可能是在尝试连接，这样你就能快速定位到“病号”是谁，这个方法是处理分布式系统问题的基本操作,很多运维手册里都会提到。

第二步，给“病号”做个体检，看看是啥症状

找到有问题的节点后，下一步就是单独连接上这个节点（用 redis-cli -h [问题节点IP] -p [端口]），看看它自己还“活”着没，可能是这个节点所在的服务器整体负载太高（比如CPU、内存用满了），导致Redis进程响应非常慢,看起来像掉线了。

这时候，你可以运行一下 info 命令，这个命令会输出一大堆信息，你不用全看,重点看几块：

1. info server：看看Redis的运行时间、版本啥的,确认进程还在。
2. info memory：看看内存使用情况，是不是内存快用满了，触发了淘汰策略，或者更糟的是设置了 noeviction 策略导致写不进去了,内存不足是常见杀手。
3. info stats：看看里面的 keyspace_hits 和 keyspace_misses，了解一下缓存的命中情况。instantaneous_ops_per_sec（每秒操作数）突然变得极低或为零,说明可能卡住了。
4. info replication：如果这个节点是从节点，这里会显示它和主节点的同步状态，看看 master_link_status 是 up 还是 down，如果断了,原因是什么。

除了看Redis本身，还得跳出Redis，去看看服务器的状况，登录到那台问题服务器上，用 top 命令看看CPU和内存整体使用率，用 dstat 或 iostat 看看磁盘I/O是不是太高了，虽然Redis主要是内存操作，但如果开了AOF持久化且配置为每次写盘（appendfsync always），磁盘压力大会拖垮整个服务，还有用 netstat 看看网络连接数是不是异常的多,可能是连接没正常关闭导致的。

第三步，对症下药，常见问题有常见解法

根据体检结果,通常能发现一些蛛丝马迹：

• 如果是网络问题：比如节点之间ping不通了，这可能是防火墙规则改了，或者云服务商的网络安全组配置错误，这时候就需要联系运维或者去云平台控制台检查网络配置，有次我们就遇到因为一次安全扫描，不小心把Redis的集群总线端口（通常是客户端端口+10000）给封了,导致节点间无法通信。
• 如果是内存爆了：赶紧看看能不能清理一些不用的key，或者临时调整一下内存淘汰策略（比如从 noeviction 改为 allkeys-lru），先恢复服务，长远来看，要么扩容,要么优化业务代码减少缓存数据量。
• 如果是节点进程真的挂掉了：去Redis的日志文件里（通常配置在redis.conf里）找错误信息，日志里经常会明确告诉你为什么挂，比如收到某种信号、内存分配失败等，根据日志错误去搜解决方案,往往最直接。
• 如果是主节点宕机，从节点没能自动切换成主节点：这可能是Redis集群的“脑裂”保护机制在作怪，要求至少有半数以上的主节点认为某个主节点下线了，才能进行故障转移，如果你的集群节点数很少（比如只有三个主节点，其中一个挂了，剩下两个因为网络分区无法沟通），就可能无法自动切换，这时候可能就需要手动执行 cluster failover 命令来强制切换了,知乎上有个关于Redis集群故障转移条件的讨论就讲得很清楚。

也是一些小技巧和经验之谈

1. 监控告警要前置：别等节点完全宕机才报警，对内存使用率、连接数、主从复制延迟这些关键指标设置阈值告警,能在问题发生前给你预警。
2. 理解集群总线：Redis集群节点之间靠一个额外的“集群总线端口”通信，这个端口通常是客户端端口加10000，一定要确保这个端口在所有节点之间的防火墙都是开放的，否则集群功能会出各种奇怪的问题,这一点很多初次搭建集群的人会忽略。
3. 谨慎操作：在问题没完全搞清楚前，不要轻易重启节点，特别是主节点，不当的重启可能会导致数据不一致，如果非要重启，尽量在业务低峰期操作,并做好数据备份。
4. 善用日志：把Redis的日志级别调到 notice 或 warning，并确保日志文件有足够的空间和合理的轮转策略，出问题时,日志是你最好的朋友。

排查Redis集群问题，就是一个“先宏观后微观，先外部后内部”的过程，从集群状态找到问题节点，然后深入检查该节点和所在服务器的资源情况，结合日志信息，大部分问题都能找到根源，希望这些实际的经验和技巧,下次你遇到类似头疼问题时能帮上忙。