全量同步不能直接传aof，因为aof是纯文本追加日志，记录写命令执行过程而非某时刻完整状态快照，缺乏时间戳和一致性边界，重放结果依赖执行顺序与中间状态，无法保证与主节点内存严格一致；而rdb通过bgsave生成原子性快照，天然具备时序封闭性，是全量同步唯一被复制流程识别的状态锚点。
全量同步为什么不能直接传AOF
因为AOF是纯文本追加日志，记录的是每条写命令的执行过程，不是某个时间点的完整状态快照。从节点加载AOF时，必须逐条重放所有命令——而这些命令可能包含大量重复、覆盖、删除操作（比如反复SET同一个key），最终结果依赖于执行顺序和中间状态，无法保证与主节点某一时刻的内存状态严格一致。
更关键的是：AOF文件本身不带“截止时间戳”或“一致性边界”。主节点在生成AOF期间仍在持续写入，你没法确定该截断到哪一行才算“当前快照”。RDB则不同，bgsave通过fork子进程捕获的是fork瞬间的内存副本，天然具备原子性与时序封闭性。
- AOF体积通常比RDB大3–5倍，网络传输耗时更长，同步窗口拉得更宽，repl_backlog更容易溢出
- RDB是二进制格式，解析快、加载快；AOF需逐行解析+执行，加载阶段阻塞更久
- Redis未实现“AOF快照截断”机制，也没有为同步场景设计AOF的增量打包协议
已有的RDB文件为什么不能复用
主节点不会读取本地已存在的dump.rdb或任何历史RDB文件来响应全量同步请求。哪怕这个文件刚生成10秒，它也不会被选中。
原因很简单：psync ? -1触发的全量同步，要求RDB必须精确反映“发起同步那一刻”的内存状态。而旧RDB文件与当前内存之间可能存在大量未持久化的写命令（尤其当配置了save但未触发、或AOF-only模式下），直接复用会导致从节点加载出过期数据。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
bgsave是唯一被复制流程识别并绑定的RDB生成方式；save会阻塞，且生成的文件不被replication逻辑感知 - 主节点在
bgsave开始后，会立即将新写命令写入repl_backlog缓冲区，这个缓冲区的起始偏移量就是RDB快照的逻辑边界 - 如果复用旧RDB，就失去了这个边界锚点，后续增量补发将完全错位
从节点加载RDB时为何必须flushdb
从节点收到RDB后不是“合并”或“增量导入”，而是强制执行flushdb再加载。这是为了消除本地残留数据对快照语义的干扰。
比如主节点RDB里没有key:session_123，但从节点本地可能还存着上一轮失败同步留下的脏数据。如果不清空，加载完RDB后这个key依然存在，违反“全量覆盖”原则。
- 加载期间从节点状态变为
loading，所有客户端命令（包括INFO、CLIENT LIST）都会返回LOADING Redis is loading the dataset in memory - 即使配置了
slave-read-only no，加载期写操作仍被拒绝——这不是权限控制，而是状态机硬限制 - 大RDB（如2GB）加载可能卡住几十秒，务必避开业务高峰发起同步
diskless复制能绕过RDB文件吗
不能。启用repl-diskless-sync yes只是跳过磁盘落盘环节，主节点依然要调用bgsave生成RDB内容，然后把RDB字节流直接通过socket发给从节点，而不是先写dump.rdb再读取发送。
也就是说，RDB仍是核心载体，只是传输路径变了：内存 → socket → 从节点内存，不再经过主节点本地磁盘。这对磁盘IO瓶颈明显的场景很有效，但没改变RDB作为一致性快照的本质角色。
- diskless模式要求主从网络稳定，单次传输中断就得重来，失败成本更高
- 从节点仍需完整接收RDB流后，才能开始
flushdb + load，加载逻辑完全一致 - 可通过
info persistence确认rdb_bgsave_in_progress:1，证明RDB生成仍在进行
