断连重连后触发的是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），否则自动拉起 + 无持久化 = 全员失忆。
