repl-backlog-size过小会导致从节点重连时因offset丢失而触发全量同步；合理值=平均写入速率（字节/秒）×最大断连时间（秒），建议上浮30%~50%；修改后需从节点重建复制连接才生效，且不宜过大以免浪费内存。
repl-backlog-size 设置太小会导致频繁全量同步
从节点断连重连后，如果主节点的复制缓冲区（repl-backlog）里已经没有从节点缺失的 offset 数据，Redis 就会触发全量同步（full resync），而不是更轻量的增量同步（partial resync）。这不仅拉高带宽和 CPU，还会让从节点长时间不可用。
根本原因不是“网络不稳定”，而是 repl-backlog-size 没撑住写入洪峰期间产生的数据量。这个缓冲区是环形的、固定大小的内存空间，只保存最近的写命令，不按时间保留，而按字节累积。
- 默认值仅
1mb，对任何稍有写压力的业务都远远不够 - 缓冲区填满后老数据被覆盖，offset 一旦被覆盖就永远丢失
- 从节点重连时携带的
run_id和offset若在缓冲区中找不到，就只能全量
怎么算出合理的 repl-backlog-size 值
核心公式是：缓冲区大小 ≥ 主节点平均写入速率 × 从节点最大断连恢复时间。注意单位统一为字节/秒和秒。
例如：主节点平均每秒写入 2MB（即 2 * 1024 * 1024 = 2097152 字节），某从节点因网络抖动最长断连过 60 秒，则最低需要 2097152 * 60 ≈ 126MB。实际建议再上浮 30%~50%，设为 180mb 更稳妥。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写入速率可通过
INFO replication中的sync_full/sync_partial_ok变化趋势 +INFO commandstats的cmdstat_set等估算，或直接用监控工具（如 Prometheus + redis_exporter）抓取redis_commands_total{cmd="set"}的速率 - 断连时间不能只看历史平均，要查日志里
Timeout waiting for data from master或Connection with master lost后到MASTER REPLICA sync started的间隔 - 多个从节点时，按「最慢/最不稳定」的那个来规划，不是取平均
修改 repl-backlog-size 后不会立即生效
这个配置属于运行时可调参数，但修改后只影响后续新建的复制连接，已存在的主从关系仍沿用旧缓冲区。必须让从节点执行 REPLICAOF no one 再 REPLICAOF <host><port></port></host> 才能触发重建复制流并使用新 backlog。
- 线上操作前确认从节点是否承担读流量，避免
REPLICAOF no one导致短暂不可读 - 不要在主节点上用
CONFIG SET repl-backlog-size后就认为万事大吉——得让从节点重新握手 - 重启 Redis 进程也会重置 backlog，但代价更大，不推荐作为常规手段
- 可通过
INFO replication中的repl_backlog_active（1 表示启用）、repl_backlog_size和repl_backlog_histlen实时核对当前值
repl-backlog-size 不是越大越好
它占用的是主节点的常驻内存，且是独占不释放的。设成 2gb 对一个写入只有 1MB/s 的实例来说，纯属浪费，还可能挤占其他关键内存（比如淘汰 key 的空间）。
- 超过
512mb就该警惕：除非你有持续数分钟的突发写入（>10MB/s），否则大概率过度配置 - 如果发现
repl_backlog_histlen长期低于repl_backlog_size的 10%，说明当前值冗余严重 - SSD 服务器上，内存比磁盘贵得多——别用磁盘思维配内存缓冲区
真正难的不是算出那个数字，而是持续观测 sync_partial_ok 和 sync_full 的比例变化，并把断连事件和 backlog 覆盖日志关联起来。一次没覆盖不等于安全，连续三次没覆盖才初步说明够用。
