最准方法是看进程启动时间：ps -eo pid,comm,lstart | grep redis-server，若多节点启动时间集中或lstart反复“跳回”，说明频繁重启；同时查哨兵日志中+switch-master是否5分钟内超3次，以及dmesg确认oom、cluster nodes验证心跳状态。
怎么看 Redis 集群是不是在频繁重启
直接看进程存活时间最准：ps -eo pid,comm,lstart | grep redis-server。如果多个节点的启动时间集中在几分钟内，或 lstart 显示的时间反复“跳回”，基本就是刚被拉起过。别只信 systemctl status redis ——它可能显示 active(running)，但背后是 systemd 不停地 Restart=always 拉活，掩盖了真实崩溃频率。
更关键的是查哨兵日志里有没有密集出现的 +sdown、+odown 和 +switch-master。用这条命令快速扫描：grep -E '\+(sdown|odown|switch-master)' /var/log/redis/sentinel.log | tail -n 50。如果 5 分钟内出现 3 次以上 +switch-master，说明主从正在“打摆子”，不是单点故障，而是集群级不稳定。
查日志时重点盯哪几类错误信息
集群日志（/var/log/redis/redis.log 或容器内 /data/redis.log）里真正要命的不是报错堆栈，而是这几类信号：
-
OOM killed process：内核 OOM killer 干掉 redis 进程的铁证，出现在dmesg -T输出里，不是 redis 自己的日志 -
Can't handle RDB format version或Bad file format reading the append only file：AOF/RDB 文件损坏，redis 启动校验失败后直接退出 -
Connection refused或timeout大量出现在节点间通信日志中（比如Node 192.168.x.x:7001 is unreachable），说明心跳超时不是偶发，而是网络或 CPU 调度严重不足 -
WARNING overcommit_memory is set to 0：这不会直接导致重启，但会引发bgsave失败 → fork 失败 → 主进程卡死 → 被 watchdog 杀掉
OOM 和心跳超时怎么区分是真问题还是假警报
先跑两行命令交叉验证：
dmesg -T | grep -i "killed process" | grep redis —— 如果有输出，100% 是 OOM；没有，就基本排除内核级内存杀进程。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -c -p 7001 cluster nodes | awk '{print $3}' | sort | uniq -c | sort -nr
<p>输出里如果有大量 <code>fail</code></p> 或 handshake 状态，且对应 IP 的节点在其他节点日志里反复报 Connection timeout，那才是心跳超时。但如果 cluster nodes 能返回完整列表，只是偶尔连不上某个节点，大概率是那个节点自身资源耗尽（CPU 100% 或磁盘 I/O 堵死），不是网络问题。
配置和系统层最容易被忽略的三个坑
这三个点不改，日志再全也白看：
-
vm.overcommit_memory = 1必须设。写进/etc/sysctl.conf并执行sysctl -p，否则bgsavefork 失败概率陡增 -
supervised systemd必须和 systemd service 文件对齐。如果redis.conf里写supervised auto，但 service 文件没配Type=notify，redis 会误判为“无法上报状态”，触发自保式退出 -
tcp-keepalive 300建议显式设。默认是 0（禁用），在云环境或 NAT 后，连接空闲 5~10 分钟就可能被中间设备静默断开，节点间误判为失联
这些不是“优化项”，是集群稳定运行的底线配置。改完别忘了 redis-cli -p 7001 config rewrite（如果启用了 CONFIG REWRITE）并滚动重启节点，避免配置漂移。
