启用repl-diskless-sync yes仅使主节点跳过磁盘写RDB，还需从节点配repl-diskless-load on-empty-db、设置repl-diskless-sync-delay 10等参数协同，否则无法真正实现无盘复制。
直接启用 repl-diskless-sync yes 就能跳过主节点磁盘写 RDB 这一步，但仅靠这一个配置远不够——它只控制“主节点是否绕过磁盘”，而从节点如何加载数据、网络延迟怎么兜底、内存缓冲区会不会爆，全得手动对齐。
主节点必须显式开启 repl-diskless-sync
Redis 4.0+ 默认是 no，不改就还是走传统磁盘复制路径。在主节点 redis.conf 中加这一行即可生效：
repl-diskless-sync yes
注意：repl-diskless-sync 只影响主节点生成 RDB 时的行为（是否落盘），和从节点无关。重启 Redis 才会加载新配置，热重载不生效。
常见错误现象：
- 改了配置但日志里仍出现
Background saving started by pid和磁盘路径，说明配置没生效或没重启 - 从节点日志有
Failed to open .rdb for reading——这不是主节点问题，而是从节点的repl-diskless-load配置不匹配导致的
从节点要配对 repl-diskless-load 才能真正无盘
主节点流式发 RDB，从节点得接得住、解得快。默认 repl-diskless-load disabled，意味着从节点仍会把收到的 RDB 先写进临时文件再加载——等于白开了主节点的无盘。
根据你的场景选一个值：
-
on-empty-db：最常用。只在从节点数据库为空时（比如新实例、刚清空）直解 socket 数据；非空时自动 fallback 到落盘模式，安全又省事 -
swapdb：高风险高收益。内存中双份数据（旧库 + 新 RDB 解析中），需预留至少 2× 当前内存用量，OOM 风险真实存在 -
disabled：保持默认，彻底规避风险，但磁盘 IO 回归原点
示例（从节点配置）：
repl-diskless-load on-empty-db
repl-diskless-sync-delay 是防抖关键
主节点开启无盘后，多个从节点几乎同时发起全量同步请求，会导致主节点为每个连接都 fork 一个子进程去生成 RDB 流——这是灾难性的 CPU 和内存开销。
repl-diskless-sync-delay 的作用就是「攒一波」：主节点收到第一个 SYNC 请求后，等几秒，把后续到达的请求一并塞进同一个 RDB 流里发出去。
- 默认值是
5秒，生产建议调到10～30 - 太小（如
1）起不到聚合效果；太大（如60）会让首批从节点等太久，影响恢复 SLA - 配合
client-output-buffer-limit slave使用，避免等待期间缓冲区溢出断连
推荐组合：
repl-diskless-sync yes<br>repl-diskless-sync-delay 10<br>client-output-buffer-limit slave 2048mb 1024mb 300
容易被忽略的内存与网络硬约束
无盘复制不是“免配置开关”，它是用内存换磁盘、用带宽换延迟。三个硬指标必须提前核对：
- 主节点内核缓冲区：RDB 流经 pipe → socket，中间依赖内核 buffer，
/proc/sys/net/core/wmem_default建议 ≥ 4MB - 从节点内存余量：
repl-diskless-load swapdb模式下，瞬时内存占用可能飙到当前数据集的 200%，INFO memory的used_memory_peak_human要留足余量 - 网络 RTT：若主从间平均延迟 > 50ms，
repl-timeout必须设为 ≥ 120，否则未发完就被判定超时断连
最后提醒一句：Redis 官方至今仍将 swapdb 标记为实验性特性，线上环境别为了那点毫秒级提升去赌 OOM 或数据错乱。真正稳的组合是 repl-diskless-sync yes + repl-diskless-load on-empty-db + 合理的 repl-diskless-sync-delay。
