判断全量或增量同步：先看主节点日志是否含FULLRESYNC（全量）或CONTINUE（增量），再结合从节点INFO replication中master_repl_offset与slave_repl_offset差值及repl_backlog_active状态；若runid不匹配则必全量。
直接看主节点日志里有没有 FULLRESYNC 或 PSYNC 响应，再结合从节点的 INFO replication 输出里的 master_repl_offset 和 slave_repl_offset 差值，就能准确判断是全量还是增量。
查主节点日志确认同步类型
Redis 主节点在响应从节点 PSYNC 请求时，会明确返回两种响应之一：
-
FULLRESYNC {runid} {offset}→ 触发全量同步（主节点 fork 子进程执行bgsave） -
CONTINUE→ 表示接受增量同步，主节点直接从repl_backlog_buffer中推送缺失命令
所以断连重连后，第一时间 grep 主节点日志：grep -i "fullresync\|continue" redis.log。如果看到 FULLRESYNC，说明没走增量；只看到 CONTINUE，基本可确认是增量同步成功。
用 INFO replication 核对偏移量是否连续
从节点执行 INFO replication，重点关注三个字段：
-
master_repl_offset：主节点当前复制偏移量（写入命令的总字节数） -
slave_repl_offset：从节点已处理到的偏移量 -
repl_backlog_active：1 表示积压缓冲区启用，0 表示未启用或已禁用
若网络闪断后 slave_repl_offset 与 master_repl_offset 的差值 ≤ repl_backlog_size（默认 1MB），且 repl_backlog_active 为 1，则大概率走的是增量；若差值远超该值（比如几百 MB），或者 repl_backlog_active 为 0，那即使没看到 FULLRESYNC 日志，也可能因缓冲区被覆盖而被迫降级为全量。
为什么 runID 变了就一定全量？
从节点重连时发送的 PSYNC 请求格式是 PSYNC <runid><offset></offset></runid>。主节点收到后先比对 runid：
- 匹配 → 检查
offset是否仍在repl_backlog范围内 → 是则CONTINUE，否则FULLRESYNC - 不匹配（比如主节点重启过）→ 直接返回
FULLRESYNC，因为旧runid对应的偏移量上下文已丢失
所以只要 INFO replication 里从节点显示的 master_replid 和上次不一样，就不用再看偏移量——必然全量。这个判断比查日志还快，redis-cli -p 6380 INFO replication | grep master_replid 一行就能验。
容易被忽略的临界点：repl-timeout 和缓冲区覆盖速度
即使网络只断了 10 秒，也可能触发全量，原因常被忽略：
-
repl-timeout默认 60 秒，但它是控制“心跳超时”，不是“断连容忍窗口”；真正决定能否增量的是repl_backlog_size和写入速率 - 如果主节点 QPS 高（比如每秒写入 2MB），而
repl_backlog_size还是默认 1MB，那断连 0.5 秒就可能覆盖掉从节点需要的偏移段 -
repl_backlog_first_byte_offset字段在INFO replication里显示缓冲区起始偏移，用它和slave_repl_offset对比，才能知道那段数据是否还在缓冲区里——这个值很少有人查，但它才是增量同步成败的最终依据
