先确认从节点角色和连接状态，再查lag值判断延迟；若lag为0但数据缺失，则排查写入是否到达主节点、数据库选择或key过期；同步卡住需检查网络丢包、client-output-buffer-limit设置及slave-read-only是否被关闭。
从节点查不到最新数据，先看 INFO replication 输出
这是最直接的切入点。连上从节点执行 redis-cli INFO replication，重点看三行：
-
role:slave—— 确认当前确实是从节点角色，不是误配成主节点 -
master_link_status:up—— 如果是down，说明主从连接已断，跳转到网络排查环节 -
lag:xx—— 这个数字代表从节点落后主节点多少秒。>1 表示已有明显延迟；持续增长说明同步卡住
如果 lag 为 0 但数据仍查不到，大概率不是复制延迟问题，而是写入没到主节点、数据库不一致或 key 过期——得回业务侧确认写操作是否真成功落到了主节点。
主从链路丢包？用 redis-cli --intrinsic-latency 5 和 ping -c 10 双验
单纯看 ping 延迟不准：Redis 复制走的是 TCP 长连接，而 ping 是 ICMP，防火墙可能放行 ICMP 却限速 TCP。更可靠的做法是：
- 在从节点机器上跑
redis-cli -h 主节点IP --intrinsic-latency 5：它会主动向主节点发心跳包并统计抖动，>50ms 或出现 timeout 就值得警惕 - 同时执行
ping -c 10 主节点IP对比：如果 ping 延迟稳定在 1ms 但 intrinsic-latency 报大量超时，基本锁定是 Redis 端口（默认 6379）被 QoS 限速、中间设备丢包或 TCP buffer 溢出 - 检查
/proc/net/snmp中的TcpRetransSegs值是否在上升：说明重传频繁，是丢包的强信号
client-output-buffer-limit slave 设置过小导致缓冲区溢出
主节点靠内存里的复制缓冲区暂存待发命令。如果从节点处理慢（比如 CPU 被占满、磁盘 IO 高），而缓冲区又太小，就会触发溢出——主节点立刻断开该从节点连接，强制其重做全量同步。此时你看到的现象是：lag 突然归零再飙升，master_link_status 在 up/down 间反复横跳。
检查方式：在主节点执行 CONFIG GET client-output-buffer-limit，典型返回类似：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
1) "client-output-buffer-limit" 2) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
其中 slave 268435456 67108864 60 表示：硬限制 256MB、软限制 64MB、软限制持续 60 秒即触发断连。若业务写入峰值高（如批量 SET + EXPIRE），这个 64MB 很容易打满。建议按峰值写入流量 × 2 秒估算缓冲区，例如每秒写入 50MB，则至少设为 slave 536870912 107374182 60。
从节点开启了写权限，导致数据被覆盖或污染
极容易被忽略的一点：从节点默认只读，但如果配置里 slave-read-only no 或运行时执行过 CONFIG SET slave-read-only no，它就允许写入。一旦业务误把读请求路由到从节点并做了写操作（比如 SET 同名 key），后续主节点同步过来的数据会被覆盖，或者因 AOF 重写/重启丢失——表现为“主节点有，从节点没有”，其实是被从节点自己改掉了。
验证方法：在从节点执行 CONFIG GET slave-read-only，必须返回 "slave-read-only" "yes"。如果为 no，立刻改回并重启，否则任何复制延迟排查都无意义。
真正麻烦的从来不是单点延迟，而是多个条件叠加：缓冲区小 + 网络偶发丢包 + 从节点 CPU 突增 + slave-read-only 被悄悄关闭。这类问题不会报错，只会让数据在某个时间点后开始“随机消失”。每次排查，优先盯死这四个位置。
