主从延迟最直接指标是master_repl_offset与slave_repl_offset差值，持续>10mb表明实质性延迟；需观察30秒以上趋势，结合--latency-history、commandstats、io负载及repl-backlog-size综合排查。
查 INFO replication 看实时复制偏移量差值
主从延迟最直接的指标不是时间，而是主从各自的 master_repl_offset 和 slave_repl_offset 差值。这个差值代表从库“漏掉”了多少字节的复制流，比 seconds_behind_master（Redis 不提供该字段）更可靠。
在主库和从库分别执行：
redis-cli INFO replication | grep repl_offset
对比两者数值，差值持续 > 10MB 通常意味着存在实质性延迟。注意：该差值会随写入节奏波动，需观察 30 秒以上趋势，而非单次快照。
- 主库
master_repl_offset是写入命令进入复制缓冲区后的累计字节数，含 AOF rewrite 期间的 fake offset 增量 - 从库
slave_repl_offset只在成功解析并执行完一条命令后才更新，卡在网络接收、命令解析、或慢命令执行阶段都会导致它滞后 - 若从库显示
slave_repl_offset长期不增长，说明复制连接已断或卡死，需检查slave_read_repl_offset（接收到但未解析的偏移量）是否在涨
用 redis-cli --latency-history 定位主库写入毛刺
高延迟常由主库突发写入引起，比如批量 SET、LPUSH 或大 key DEL，它们会阻塞主线程，拖慢复制缓冲区刷新频率。
在主库上运行：
redis-cli --latency-history -i 1
观察输出中是否有周期性 > 5ms 的延迟尖峰，尤其匹配业务定时任务或日志上报窗口。
- 若尖峰与
redis-cli INFO commandstats中cmdstat_set:calls=或cmdstat_del:usec_per_call异常升高时段一致，基本可锁定写入压力源 - 避免用
MONITOR抓包排查——它本身就会加重延迟，仅作最后手段 - 写入毛刺不一定来自应用层：某些 Lua 脚本执行超时、RDB save 子进程 fork 阻塞、或内存碎片率（
mem_fragmentation_ratio> 1.5）都可能引发类似现象
检查从库磁盘 IO 是否成为瓶颈（尤其开启 AOF 时）
从库在重放复制流时，若同时启用了 appendonly yes，每条写命令都会触发一次 fsync（取决于 appendfsync 策略），极易被磁盘吞吐拖住。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
确认从库配置：
redis-cli CONFIG GET appendonly
再看 IO 实时负载：
iostat -x 1 | grep nvme0n1 # 替换为实际设备名
重点关注 %util（持续 > 90%）、await（> 20ms）和 svctm（反映真实服务耗时）。
- 若
appendonly开启且appendfsync everysec，延迟常表现为周期性堆积（每秒 flush 一次，积压在缓冲区） -
appendfsync no可显著缓解，但牺牲持久性；生产环境建议改用everysec+ SSD + 单独挂载数据盘，避免与系统盘混用 - 从库禁用 AOF 是常见做法——它只读，无需落盘保障；只需确保主库 AOF 安全即可
确认复制缓冲区（repl-backlog）是否过小或被反复覆盖
当从库短暂断连后重连，靠 repl-backlog 进行部分同步（PSYNC）。如果 backlog 太小或写入太快，它会被新数据覆盖，导致从库被迫全量同步（SYNC），进一步加剧延迟和带宽压力。
检查当前配置：
redis-cli CONFIG GET repl-backlog-size
默认 1MB，对中高流量场景远远不够。
- 估算公式：
repl-backlog-size ≈ 主库平均每秒写入字节数 × 断连容忍秒数 × 2（留冗余） - 例如主库写入 5MB/s，要求容忍 60 秒断连，则设为
CONFIG SET repl-backlog-size 60000000（约 60MB） - 该参数动态生效，但重启后丢失；务必写入
redis.conf持久化 - 若
INFO replication显示repl_backlog_active:0，说明 backlog 已被禁用或未初始化，需检查repl-backlog-size是否为 0
真正难排查的是复合问题：比如主库 CPU 软中断过高导致网络收包延迟，叠加从库机械盘 fsync 慢，再遇上 backlog 不足引发频繁全量同步——这种链路级瓶颈，必须逐段验证，不能只盯一个指标。
