Redis 主从复制延迟如何从 offset 判断

Redis 副本出现“读到旧数据”时，先不要把 offset 差值当成毫秒延迟。更稳妥的判断是：在同一复制历史下，用主库的 master_repl_offset 减去副本的 slave_repl_offset，得到副本在复制流位置上落后的字节距离；再结合链路状态、同步状态和 backlog 覆盖范围，判断它是在正常追赶，还是已经需要全量同步。

先看 INFO replication：offset 差值到底表示什么

Redis 的复制 offset 会随着复制流字节推进。主库用 master_repl_offset 表示当前产生到哪里，副本用 slave_repl_offset 表示处理到哪里。两者属于同一 replication ID 时，可以先做一个位置差计算：

# 分别在主库和副本读取复制字段；示例值只用于说明计算方法
redis-cli INFO replication | egrep '^(role|master_replid|master_repl_offset|slave_repl_offset|master_link_status|master_sync_in_progress|master_last_io_seconds_ago):'

# 用主库 offset 减去副本 offset，得到复制流位置差
master_offset - replica_offset

例如主库 offset 是 1250000，副本 offset 是 1242000，差值为 8000。它说明副本还差约 8000 字节的复制流，不说明一定慢了 8000 毫秒。写入命令大小不同，字节数和时间的对应关系也会变化。

再看链路和同步状态：别把全量同步当普通延迟

同一个差值在不同状态下含义不同。可以按下面的检查表判断：

生产排查时至少采样两三次。若链路为 up、没有全量同步，且差值在写入高峰后下降，通常是短时追赶；若链路为 down，先修复连接；若正在同步，则应观察同步进度和资源压力，不要只调大 backlog。

backlog 能否覆盖缺口，决定断线后怎么恢复

主库保留一段复制 backlog。repl_backlog_first_byte_offset 表示这段缓冲区的起始位置，repl_backlog_histlen 表示当前保存的数据长度。可以把可用范围理解为：

# 读取主库 backlog 的覆盖窗口；不要把它当作副本当前 offset
redis-cli INFO replication | egrep '^(master_repl_offset|repl_backlog_active|repl_backlog_first_byte_offset|repl_backlog_histlen|repl_backlog_size):'

# 逻辑判断：副本需要的起点落在 backlog 覆盖范围内，才有机会部分同步
backlog_end = first_byte_offset + histlen - 1

副本断线后，如果主库仍保留它缺少的那段复制流，Redis 可以通过 PSYNC 补增量；如果缺口已经早于 backlog 起点，历史数据被覆盖，就只能走全量同步。这里的“延迟”因此不只是 offset 数字，还包括写入速率、断线时长和 backlog 容量。

用连续采样做最后确认

建议把主库 offset、副本 offset、差值、链路状态和同步状态放在同一张监控表里，每次采样保留时间戳。差值短时升高后回落，通常是副本追赶；差值长期扩大，才需要继续查副本 CPU、磁盘、网络、命令流量和客户端读流量。backlog 也要按实际写入速率估算覆盖时间，不能只看“几 MB”这个绝对数。

常见问题

offset 差值能直接换算成毫秒吗？

不能。它是复制流位置的字节差；要估算时间，还需要一段时间内的写入速率和副本追赶速率。

副本 offset 比主库大怎么办？

先确认两边角色、replication ID 和采样时间，再检查是否发生故障转移或角色切换。不要直接用绝对值判断数据新旧。

backlog 越大就一定不会全量同步吗？

不是。backlog 只能覆盖保留下来的复制流；断线时间、写入速率和复制 ID 不匹配仍可能触发全量同步。