断连重连后触发的是psync增量同步或fullresync全量同步，取决于runid是否匹配及offset是否在repl-backlog缓冲区内：匹配且offset有效则增量同步，否则全量同步。

会自动同步，但是否“全量”还是“增量”，取决于断连时长和主节点配置。

断连重连后触发的是 PSYNC 增量同步还是 FULLRESYNC 全量同步？

Redis 2.8+ 使用 PSYNC 替代旧版 SYNC，核心判断依据是两个元数据：runid 和 replication offset。从节点重连时会带上自己记录的主节点 runid 和当前已同步到的偏移量。

• 如果 runid 匹配且主节点积压缓冲区（repl-backlog-buffer）中仍保留从节点缺失的命令（即 offset 落在缓冲区内），则走增量同步：主节点只发送缺失的写命令
• 如果 runid 不匹配（比如主节点重启过），或 offset 已被缓冲区覆盖（断连太久），则强制触发 FULLRESYNC：主节点执行 BGSAVE、传输 RDB、再补发后续命令

默认积压缓冲区大小为 1MB，可通过 repl-backlog-size 调大；缓冲区是环形结构，旧命令会被新命令覆盖。

为什么有时看起来“没自动恢复”，其实是卡在加载阶段？

从节点收到 RDB 后必须先清空自身数据，再加载新快照。这个过程默认会阻塞客户端请求（返回 LOADING 错误），直到加载完成。

Redis Skill - 高性能缓存管理

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

下载

• 若 RDB 很大（比如几 GB），加载可能持续数秒甚至分钟，期间所有读请求失败
• 可通过配置 slave-serve-stale-data yes 让从节点在加载期间继续用旧数据响应读请求（牺牲强一致性换可用性）
• 注意：该配置不影响同步逻辑本身，只影响对外服务行为

replicaof 配置写错或网络抖动导致反复断连怎么办？

频繁断连会放大同步开销，尤其全量同步对主节点 CPU 和带宽压力明显。常见诱因：

• 从节点配置了错误的主节点地址或端口，启动后不断尝试连接失败，日志刷屏 Unable to connect to MASTER
• 主从间网络不稳定，TCP 连接频繁中断，触发重复 PSYNC 尝试
• 主节点 maxmemory 触发淘汰策略，导致部分 key 突然消失，从节点同步后状态不一致（这不是同步机制问题，但常被误判）

排查优先看从节点日志：连续出现 Master does not support PSYNC 表示主节点太老（Connection with master lost 后紧接 Partial resynchronization not possible 就说明进了全量流程。

真正容易被忽略的是积压缓冲区的生命周期——它只存在于主节点内存中，主节点重启后整个缓冲区清空。哪怕你设置了 repl-backlog-size，只要主节点挂过一次，所有从节点重连都只能走全量。所以生产环境主节点必须开启持久化（RDB 或 AOF），否则自动拉起 + 无持久化 = 全员失忆。