增大repl-backlog-size可避免断连后全量同步，因其为主节点提供足够大的环形缓冲区暂存断连期间的写命令；只要从节点重连时请求的slave_repl_offset仍在该缓冲区内（即master_repl_offset−slave_repl_offset≤repl_backlog_histlen），即可触发PARTIALRESYNC实现增量同步。
repl-backlog-size太小导致缓冲区被覆盖
主从断开后能否增量复制，取决于从节点断连期间的命令是否还在主节点的repl-backlog-buffer中。这个缓冲区是环形结构，写满后老数据会被新命令覆盖。Redis 7.0默认repl-backlog-size只有1mb，高压写入下几秒就溢出——从节点重连时请求的offset已不在缓冲区里，只能触发全量同步。
- 用
INFO replication查repl_backlog_active和repl_backlog_size确认当前值 - 生产环境建议设为
512mb或更高：CONFIG SET repl-backlog-size 536870912 - 该配置不持久，需同步写入
redis.conf中的repl-backlog-size项
client-output-buffer-limit slave限制过严
主节点要同时干三件事：生成RDB、写入repl-backlog-buffer、向所有从节点推送增量命令。这三路输出共用同一个client-output-buffer-limit slave缓冲区。默认配置slave 256mb 64mb 60（60秒内累计超64mb就断连），在多从+高QPS场景下极易触发强制断开，导致“刚连上又断”循环。
- 立即生效调大：
CONFIG SET client-output-buffer-limit "slave 1024mb 512mb 120" -
repl-backlog-size和client-output-buffer-limit必须一起调，只改一个无效 - 注意单位是字节，不是MB字符串；引号不能省，否则解析失败
repl-timeout设置过短引发误判断连
主从之间靠REPLCONF ACK {offset}心跳维持连接状态。从节点每秒发一次ACK，主节点若在repl-timeout秒内没收到，就认为从节点失联并主动关闭连接。Redis 7.0默认repl-timeout是60秒，但网络抖动、GC停顿或瞬时拥塞都可能导致ACK延迟到达。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 建议设为
300：CONFIG SET repl-timeout 300 - 该值不是越长越好——过长会掩盖真实故障，需结合监控看
master_repl_offset - slave_repl_offset差值趋势 - 别忘了检查
repl-backlog-ttl（默认3600），它控制缓冲区空闲多久后自动释放，也影响增量恢复窗口
主从Redis小版本不一致导致握手失败
Redis 7.0.x系列内部协议有细微调整，主从节点小版本不一致（比如主是7.0.15，从是7.0.12）会在PSYNC握手阶段静默失败。日志里只显示MASTER ，然后连接关闭，不报错也不重试。
- 必须用
redis-server --version逐台核对，不能只看大版本号 - 升级时优先升级从节点，再升主节点，避免反向兼容问题
- 特别注意：Redis 8.2.3修复了CVE-2025-62507等高危漏洞，建议直接升级到该版本而非仅打补丁
真正卡住增量复制的，往往不是某个单一参数，而是repl-backlog-size、client-output-buffer-limit、repl-timeout三者配合失当，再加上版本校验这种“看不见的墙”。调参前先抓一段断连时的INFO replication输出，比盲目改配置有用得多。
