直接连主从节点执行INFO replication，重点看master_repl_offset、slave_repl_offset和master_sync_in_progress三行；若后者为1，说明正全量同步，slave_repl_offset不更新，差值无效。
用INFO replication抓取主从offset原始值
直接连上主节点和从节点，分别执行redis-cli -p 6379 INFO replication，重点看三行：master_repl_offset（主库当前写入位置）、slave_repl_offset（从库已应用位置）、master_sync_in_progress（是否正在全量同步）。别只抄两个offset相减——如果master_sync_in_progress:1，说明从库还在加载RDB，此时slave_repl_offset根本不会更新，差值毫无意义。
为什么slave_repl_offset比master_repl_offset小几百还报“同步正常”
常见于从库CPU或磁盘IO瓶颈，命令重放不过来。这时master_last_io_seconds_ago可能仍小于5秒（心跳正常），但slave_repl_offset增长缓慢甚至停滞。可对比used_memory_peak_human：若从库峰值内存明显高于主库，大概率是遇到bigkey解析卡住；再查commandstats里cmdstat_hgetall或cmdstat_eval调用量是否异常飙升。
脚本化监控offset差值时必须绕开的三个坑
- 不能只靠一次采样判断异常：offset差值瞬时跳几万可能是主库突发写入，要连续采样5次、间隔2秒，看差值是否持续扩大且>10MB
- 忽略
repl_backlog_active状态：若为0，说明复制积压缓冲区已停用，后续任何断连都会强制全量同步，此时offset差只是表象，根因在主库配置 - 把
connected_slaves当一致性指标：它只表示TCP连接存活，哪怕值为1，master_repl_offset−slave_repl_offset不为0就代表有命令没执行完
手动触发PSYNC前先确认runid和offset是否有效
从节点执行ROLE，返回数组第二项是"stable_sync"才代表当前处于增量同步态；若为"connect"或"loading"，说明还没完成握手或RDB加载，此时发PSYNC <runid><offset></offset></runid>会被主节点无视。另外，主节点日志里搜"Partial resynchronization request accepted"才是PSYNC2真正生效的证据；若看到"Full resync requested"，说明repl-backlog-size太小或repl-backlog-ttl已超时——这两个参数一旦设死，再精准的offset也救不回部分同步。
repl-backlog-size够不够撑住预期断连时长、从节点有没有误开slave_read_only no导致写入阻塞、以及每次全量同步后主库master_repl_offset是否在RDB传输窗口期继续疯涨。这些点不厘清，光捕获offset差值只是给报警系统喂噪音。 
