主从 offset 差值持续增大说明 repl_backlog_buffer 未兜住增量写入，根因包括从节点拉取慢、断连久或主节点写入猛导致缓冲区被覆盖；需结合写入速率与断连时长估算并合理配置 repl-backlog-size。

主从 offset 差值持续增大，说明 repl_backlog_buffer 没兜住增量写入

Redis 主从复制靠 offset 对齐进度，主节点每写一条命令就推进 master_repl_offset，从节点同步完就更新 slave_repl_offset。两者差值变大，本质是：从节点拉得慢、断连时间长，或主节点写得太猛，导致 repl_backlog_buffer（环形缓冲区）被覆盖。

• repl_backlog_buffer 默认只有 1MB，高写入场景下几秒就刷没；一旦从节点重连时需要的 offset 被覆盖，就只能触发全量同步（PSYNC fullresync）
• 查当前积压量：redis-cli info replication | grep -E "offset|backlog"，重点关注 repl_backlog_active:1、repl_backlog_size 和 repl_backlog_histlen
• 真正决定能否增量恢复的是 repl_backlog_histlen —— 它代表当前缓冲区里还剩多少字节有效数据，不是看 size

怎么调 repl-backlog-size 才不白调

光加大 repl-backlog-size 不够，必须结合从节点平均断连时长和主节点写入速率估算。设写入速率为 R（B/s），预期最大断连时间为 T（s），那最小 backlog 应 ≥ R × T × 1.2（留 20% 冗余）。

• 例如：主节点平均每秒写入 500KB，从节点网络抖动最长 30 秒，则建议 repl-backlog-size 18000000（≈17MB）
• 配置在 redis.conf 中，改完需重启或用 CONFIG SET repl-backlog-size 18000000（注意：该命令不会持久化到配置文件）
• ⚠️ 不能无脑设成 1GB：过大的 backlog 会占用主节点内存，且 Redis 启动时会预分配整块内存，可能触发 OOM

PSYNC 返回 FULLRESYNC 却没触发 bgsave，说明复制积压缓冲区已失效

正常情况下，从节点重连发 PSYNC ，主节点查 offset 是否在 backlog 范围内。如果返回 FULLRESYNC，但主节点日志里没有 Background saving started by pid，大概率是：slave_repl_offset 请求的 offset 已不在 backlog 可覆盖范围内，或主节点 runid 已变更（如主节点重启过）。

• 检查主节点 runid 是否变化：redis-cli INFO server | grep run_id，对比从节点上次记录的 runid（INFO replication 中的 master_run_id）
• 确认 backlog 是否活跃：repl_backlog_active:0 表示缓冲区根本没启用（比如主节点从未有从节点连接过）
• 从节点 log 出现 Connecting to MASTER → 紧接着 MASTER REPLICA sync: receiving streamed RDB，说明走的是全量，不是增量

从节点延迟高 + offset 差值跳变，优先查网络和从节点 CPU

offset 差值不是缓慢增长，而是突然跳几百上千万，往往不是 backlog 太小的问题，而是从节点卡住了——比如磁盘 IO 堵塞（AOF rewrite + RDB save 同时跑）、CPU 满载、或 TCP 接收缓冲区溢出。

• 查从节点负载：top -p $(pgrep redis)，关注 %CPU 和 %MEM；用 iostat -x 1 看 await 和 %util
• 检查是否开启了 no-appendfsync-on-rewrite yes，否则 AOF rewrite 期间 fsync 会被阻塞，拖慢复制命令执行
• 观察 slave_repl_offset 是否“停走”：连续几次 INFO replication 查到它不变，基本锁定从节点处理卡死

复制偏移量问题最麻烦的地方在于：现象相似（比如 offset 差很大），但根因可能是 buffer 配置、网络抖动、从节点资源瓶颈、甚至主节点重启后 runid 重置 —— 必须按顺序排除，不能只盯着 repl-backlog-size 狂调。