info replication 的 offset 对不上时，不能仅凭 master_repl_offset 与 slave_repl_offset 差值判断从库落后，需结合 master_sync_in_progress、repl_backlog_active、master_last_io_seconds_ago 等字段综合分析同步状态与瓶颈原因。
INFO replication 返回的 offset 为什么对不上
主从数据不一致时，INFO replication 是第一手排查依据，但很多人直接比对 master_repl_offset 和 slave_repl_offset 就下结论“从库落后”，其实忽略了中间环节——从库可能还没把接收到的复制流写入内存，或正在阻塞解析。真正反映同步进度的是 slave_repl_offset（从库已应用的偏移量），而非 slave_pending_bio_offset 或 slave_pending_side_table_offset 这类缓冲区指标。
常见错误现象：slave_repl_offset 比 master_repl_offset 小几百甚至几千，但 role 显示 slave、master_link_status 是 up，看起来一切正常。
- 检查前先确认从库是否处于
SYNC状态（master_sync_in_progress:1表示正在全量同步，此时slave_repl_offset不更新，属正常） - 若
master_sync_in_progress:0且slave_repl_offset滞后，优先查repl_backlog_active是否为1；若为0，说明复制积压缓冲区已停用，主库断连后无法部分重同步，只能全量重拉 -
slave_repl_offset滞后但差值稳定不增长，可能是从库 CPU 或磁盘 I/O 瓶颈导致命令执行慢，不是网络问题
如何判断是网络延迟还是从库处理卡顿
光看 offset 差值无法定位瓶颈，得结合时间维度和子状态字段交叉验证。
- 观察
master_last_io_seconds_ago：若大于repl-timeout（默认 60 秒），说明主从心跳超时，连接可能已中断或假死；小于 5 秒但 offset 持续拉大，大概率是从库处理不过来 - 检查
slave_priority和slave_read_only：如果slave_read_only:0，要确认业务是否误写了从库，写入会阻塞复制流解析（Redis 6.0+ 会报READONLY You can't write against a read only slave.，但旧版本可能静默失败） - 对比
used_memory_peak_human在主从上的差异：若从库峰值内存远高于主库，可能是 bigkey 解析耗时过长，拖慢 offset 推进
offset 差异超过 repl-backlog-size 怎么办
当 master_repl_offset - slave_repl_offset > repl-backlog-size，从库无法进行部分重同步（PSYNC），会触发全量同步（SYNC）。这不仅加重主库压力，还会在 master_repl_offset 继续增长时造成二次追赶困难。
- 查看当前积压缓冲区大小：
repl_backlog_size（字节）、repl_backlog_histlen（当前有效字节数）；若histlen长期接近size，说明缓冲区太小 - 增大配置需重启或动态设置：
CONFIG SET repl-backlog-size 10485760（10MB），但注意该值只影响新连接的从库，已有连接仍用旧 buffer - 若已发生全量同步，观察
master_sync_in_progress和rdb_changes_since_last_save：后者持续上涨说明主库写入频繁，RDB 文件可能一直生成不完
从库 offset 突然回退或跳变的可能原因
正常情况下 slave_repl_offset 单调递增。如果发现它减少或跳跃式增长（比如从 123456 变成 124000 再跳到 130000），基本可锁定为以下几种情况：
- 从库被手动执行了
SLAVEOF NO ONE后又重新SLAVEOF，会丢弃旧复制上下文，从新位置开始同步 - 主库执行了
DEBUG RELOAD或意外崩溃重启，且未启用 RDB/AOF 持久化，导致master_repl_offset归零，从库重连后只能全量同步 - 使用了 Redis Cluster 且节点角色变更（如 failover 后原主变成从），但客户端仍往旧地址发请求，造成写入丢失、offset 错乱
- 某些代理层（如 Twemproxy、Codis）不透传复制协议，导致从库看到的 offset 来源不可信
offset 跳变往往意味着数据已不可逆丢失，不能只依赖 INFO 输出，必须结合慢日志、监控曲线和业务侧写入日志交叉比对。尤其要注意 slave_repl_offset 回退时，master_link_status 很可能短暂变为 down，但 INFO 命令采样未必能捕获那一瞬。
