从节点异常重启主因是主节点output buffer limit触发断连并引发重同步失败循环，需同步调大主从repl-timeout、检查omem≥64MB、client_longest_output_list>0及dmesg中OOM killer记录。
看从节点进程存活时间是否异常跳回
直接执行 ps -eo pid,comm,lstart | grep redis-server，重点观察从节点进程的 lstart 时间。如果多个从节点启动时间集中在同一分钟内，或反复出现“刚起来不到 1 分钟就又换了个时间”，说明不是正常运行，而是被 systemd 或容器引擎反复拉起。此时 systemctl status redis 显示 active(running) 是误导性的——它只反映当前状态，不反映崩溃频率。
查主节点日志里有没有 "output buffer limit" 强制断连
从节点频繁重启，常因主节点主动踢掉连接后触发重同步失败循环。关键证据在主节点日志中：Client closed connection due to output buffer limit。确认方法有三：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在主节点执行
CLIENT LIST，找对应从节点 client 行，盯omem字段（不是qbuf）是否持续 ≥ 64MB - 用
grep "output buffer" /var/log/redis/redis.log确认错误匹配 -
redis-cli info clients中client_longest_output_list长期 > 0，说明输出队列积压
检查 repl-timeout 是否在主从两端都调大
默认 repl-timeout 60 在高延迟或磁盘慢的从节点上极易触发断连。但只改从节点没用——主节点仍按自己配置判定“失联”。必须同步操作：
- 主节点配置
repl-timeout 120，再执行CONFIG REWRITE或重启生效 - 从节点也设为
repl-timeout 120，否则它等不及 ACK 就自行断开 - 别设成 300：故障发现窗口会拉太长，且掩盖真实链路问题
别漏掉 dmesg 里的 OOM killer 记录
从节点进程被杀，未必是 Redis 自己退出，很可能是内核 OOM killer 动的手。跑这行命令：dmesg -T | grep -i "killed process" | grep redis。如果有输出，说明内存真的不够，maxmemory、overcommit_memory、容器内存限制都要查。没有输出，则基本排除内核级杀进程，可聚焦网络和配置层面。
client-output-buffer-limit 触发断连 → 重同步卡住 → repl-timeout 再次超时 → 主节点拒绝新 SYNC → 从节点启动失败退出 → 被拉起……这个闭环里，只调一个参数根本打不住。 
