真延迟需观察主从offset差值是否持续扩大且从库slave_repl_offset长时间不动；sync状态、慢命令阻塞、repl-backlog过小、网络丢包或swap启用等均会导致offset异常。
怎么看主从 offset 差异是否真延迟
直接比 INFO replication 里 master_repl_offset 和从库的 slave_repl_offset 不够——这俩差值大，只说明「从库还没追上」，但不等于「正在延迟」。可能只是刚启动、网络卡顿、或主库写入突增。关键看差值是否持续扩大，且从库 slave_repl_offset 长时间不动。
- 在主库执行
redis-cli INFO replication | grep master_repl_offset，记下值（比如123456789） - 在从库执行
redis-cli INFO replication | grep slave_repl_offset，记下值（比如123450000） - 间隔 5 秒再查一次，如果差值从
6789变成12789，且slave_repl_offset没动，才是真问题 - 注意：从库若处于
SYNC状态（全量同步中），slave_repl_offset会是0或远低于主库，这是正常过程，不算“延迟”
为什么从库 replay 很慢但 offset 不涨
offset 是复制流位置，不是命令执行进度。从库收到数据后先写入复制缓冲区，再串行解析执行。如果命令本身耗时高（比如大 key 的 HGETALL、KEYS *、Lua 脚本阻塞），就会卡住 repl thread，导致 slave_repl_offset 停滞，但复制流其实还在收。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查从库
INFO commandstats中cmdstat_hgetall:calls=或cmdstat_eval:calls=是否异常高 - 用
redis-cli --latency -h看实际响应毛刺；若 P99 > 100ms，大概率是慢命令积压 - 开启
slowlog-log-slower-than 10000（单位微秒），查SLOWLOG GET 5看最近慢命令 - 注意：从库禁用
lua-time-limit会导致 Lua 无限运行，彻底堵死复制线程
主库配置不当放大延迟风险
主库的 repl-backlog-size 和 repl-timeout 直接影响从库断连后能否靠增量恢复。设太小，从库短暂抖动就触发全量同步（SYNC），一来一回几十秒起步，offset 差直接归零再重拉。
- 计算 backlog：按主库每秒写入量 × 期望容忍断连秒数 × 1.5（预留冗余），例如写入 5MB/s，想撑 60 秒，至少设
repl-backlog-size 45000000（45MB） -
repl-timeout默认 60 秒，但网络波动常见于 3–5 秒丢包，建议调到30，避免误判断连 - 主库若启用了
repl-diskless-sync yes，但从库磁盘 I/O 差，会导致 RDB 生成快、传输慢，间接拖慢 offset 推进 - 禁用
tcp-nodelay no（即启用 Nagle 算法）会让小包攒批发，增加复制流延迟，生产环境应设为yes
网络和系统层干扰常被忽略
Redis 复制走普通 TCP 连接，任何中间环节丢包、限速、buffer 溢出都会让从库收包慢，表现就是 slave_repl_offset 上升缓慢，甚至停滞几秒。
- 在从库上用
tcpdump -i any port 6379 -w redis-repl.pcap抓包，过滤主库 IP，看是否有大量重传（TCP Retransmission） - 检查
/proc/net/snmp中Tcp:行的RetransSegs是否持续增长 - 确认主从间 MTU 是否一致，云厂商 VPC 内有时默认 1500，但某些隧道叠加后实际只有 1400，导致分片丢弃
- 从库所在机器若 swap 使用率 > 20%，Redis 进程可能被交换出去，
slave_repl_offset会突然卡住数秒再跳变
