从节点重启后必然触发全量同步，因其内存中master_replid和slave_repl_offset清空，只能发送psync ? -1，主节点据此判定无法增量同步而响应fullresync。
从节点重启后 master_replid 和 offset 丢失是根本原因
Redis 从节点重启时，内存中保存的 master_replid（即主节点 run_id）和 master_repl_offset 全部清空。它再连接主节点时只能发 PSYNC ? -1，这在 PSYNC2 协议里明确表示“我啥都不记得了”，主节点别无选择，只能响应 +FULLRESYNC。这不是配置问题，也不是 bug，而是协议设计的兜底逻辑。
repl-backlog-size 再大也救不了重启后的从节点
很多人误以为调大 repl-backlog-size 就能避免重启后的全量同步——但这是错的。因为从节点重启后 slave_repl_offset 归零，而主节点的 repl_backlog_first_byte_offset 是一个正数（比如 100000），此时 0 ，直接不满足增量同步的 offset 区间条件。哪怕 backlog 有 512MB，只要 offset 不在范围内，就进不了增量流程。
RDB 预热能跳过全量同步，但必须手动干预
真正有效的缓解方式不是等启动后同步，而是让从节点“带着数据启动”：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点执行
BGSAVE或确认最近一次 RDB 时间戳最新 - 把该
dump.rdb拷贝到从节点的dir目录下，文件名必须与dbfilename一致（默认就是dump.rdb） - 确保从节点配置中
rdb-del-sync-files no（否则它启动时会删掉你放好的 RDB） - 启动前删掉
nodes.conf，避免残留集群状态干扰角色识别
做完这些，从节点启动后会加载本地 RDB，并尝试基于该文件末尾的 offset 发起 PSYNC，有很大概率直连增量同步。
分批重启比参数调优更重要
即使做了 RDB 预热，也不要所有从节点一起启。每个节点启动后仍要完成握手、复制流注册、缓冲区初始化，这些动作共享主节点的连接数、CPU 调度和网络缓冲区。实测中，5 个从节点同时启动，主节点 used_cpu_sys 瞬间飙高 40%，client_longest_output_list 堆积超阈值，反而触发连接驱逐。建议按批次间隔 30 秒以上重启，并用 redis-cli -p 7002 info replication | grep sync_ 观察 master_sync_in_progress 是否快速归零。
最容易被忽略的一点：RDB 预热成功与否，不能只看日志有没有 “Loading DB” —— 必须检查从节点 INFO replication 中的 slave_repl_offset 是否在几秒内开始追 master_repl_offset。如果卡在 master_sync_in_progress:1 超过 10 秒，大概率是 RDB 文件权限不对、路径没对上，或者 rdb-del-sync-files yes 悄悄把它删了。
