slave_repl_offset代表从节点已成功执行的复制命令总字节数，是真正落地的同步进度；比master_repl_offset小几百是否异常需结合master_sync_in_progress、master_last_io_seconds_ago等字段综合判断。

直接执行 INFO replication 查看从节点当前偏移量

连接到从节点后运行 INFO replication，输出中关键字段是 slave_repl_offset ——它代表该从节点**已成功执行**的复制命令总字节数，也就是真正“落地”的进度。别误读成接收缓冲区里的数据量，slave_pending_bio_offset 或 slave_pending_side_table_offset 这类字段只是中间状态，不反映实际应用进度。

slave_repl_offset 比 master_repl_offset 小几百正常吗？

不一定异常，得结合其他字段交叉判断：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 先确认 master_sync_in_progress:0：如果是 1，说明正在全量同步，slave_repl_offset 不更新属正常
• 检查 master_last_io_seconds_ago：若大于 60（默认 repl-timeout），主从心跳已超时，连接可能假死
• 观察 slave_repl_offset 差值是否稳定：差值不变但持续存在，大概率是从库 CPU 或磁盘 I/O 卡住，不是网络问题
• 留意 slave_read_only:1：如果为 0，要排查业务是否误写从库，Redis 6.0+ 会报 READONLY You can't write against a read only slave.，旧版本可能静默阻塞复制流

为什么只比对两个 offset 会误判同步延迟？

因为 master_repl_offset 是主节点“发出去”的字节数，slave_repl_offset 是从节点“执行完”的字节数，中间隔着网络传输、接收缓冲、命令解析、内存写入多个环节。常见陷阱包括：

• 从节点 used_memory_peak_human 显著高于主节点 → 可能有 bigkey 解析耗时长，拖慢 offset 推进
• repl_backlog_active:0 → 复制积压缓冲区被禁用，断连后只能全量重同步，无法靠 offset 差值做增量追赶
• master_repl_offset - slave_repl_offset > repl_backlog_size（默认 1MB）→ 积压缓冲区已兜不住，必然触发全量同步，此时 offset 差值失去增量参考意义

哨兵模式下怎么批量查所有从节点的 offset？

在任意 Sentinel 节点上执行：SENTINEL slaves <master-name></master-name>，返回结果里每个从节点都有 offset 字段，对应的就是它的 slave_repl_offset。注意这个 offset 是 Sentinel 从对应从节点 INFO replication 中拉取的快照值，不是实时连续指标；若需精确监控，应定期直连各从节点抓取 INFO replication，避免经由 Sentinel 引入额外延迟或缓存偏差。