无盘复制通过跳过主节点RDB落盘、由子进程直接流式发送数据至从节点，规避磁盘寻道与IO竞争，从而加速初始化；但需合理配置repl-diskless-sync-delay（建议10～30）和client-output-buffer-limit，否则易引发CPU/内存雪崩。
开启 repl-diskless-sync 能显著加快主从初始化速度，但默认配置下几乎必然引发主节点 CPU 或内存雪崩——关键不在“开不开”，而在怎么配、配多大、配给谁。
为什么无盘复制能加速初始化？
传统全量同步要走“fork → 写 RDB 到磁盘 → 读 RDB → 发送”四步，其中两次磁盘 IO（尤其是写）在高负载或云盘环境下极慢。无盘复制跳过落盘环节，fork 后子进程直接压缩并流式写入 socket，省掉磁盘寻道和顺序写延迟。
但这只是理论加速；实际中若没配好 repl-diskless-sync-delay 和 client-output-buffer-limit，主节点可能瞬间 fork 出十几个子进程，CPU 打满、内存暴涨，反而比有盘还慢。
repl-diskless-sync-delay 设多少才合理？
这个参数不是“延迟越小越好”，也不是“越大越稳”，它是主节点对多个 SYNC 请求的“攒批窗口”。设得太小（比如 1），起不到聚合效果，仍会高频 fork；设得太大（比如 60），首批从节点要干等一分钟，SLA 直接破防。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生产环境建议设为
10～30，视从节点规模动态调整：2～5 个从节点用10，10+ 个用20～30 - 必须配合
INFO REPLICATION观察master_repl_offset和slave0:offset差值变化节奏，确认是否真有多个请求被合并 - 如果发现
repl-backlog-histlen长期接近repl-backlog-size，说明攒批期间积压命令太多，需同步加大 backlog
client-output-buffer-limit slave 必须同步调大
无盘复制下，主节点不再依赖磁盘暂存数据，所有待发送的 RDB 流都堆在内存里。若从节点接收慢（比如网络卡顿、自身 load 高），缓冲区溢出就会触发断连，重试时又来一轮 fork —— 这是线上最常见 OOM 杀进程原因。
典型错误配置：repl-diskless-sync yes 却沿用默认 client-output-buffer-limit slave 256mb 64mb 60。
- 建议至少设为
client-output-buffer-limit slave 1024mb 256mb 120（即硬限 1GB，软限 256MB，超软限持续 120 秒才断连） - 若主节点可用内存 2GB，开无盘前务必确认
maxmemory留足 1.5 倍余量 - 跨机房部署（如主在北京、从在新加坡）慎用：网络抖动导致传输中断，无法像有盘模式那样从 RDB 文件断点续传
哪些场景根本不该开 repl-diskless-sync？
无盘复制本质是把磁盘压力转嫁给内存和网络，它不是通用加速器。
- 主节点内存紧张：可用内存
- 从节点网络不稳定：丢包率 > 0.5% 或 RTT 波动 > 50ms，重传成本远高于本地读 RDB
- 主节点写入吞吐极低但从节点数量极少（仅 1～2 个）：此时有盘模式更稳，且 fork 开销可忽略
真正受益的场景很具体：主节点 SSD IO 已打满 + 从节点 ≥ 5 个 + 网络带宽充足 + 内存余量 > 3GB。其他情况，优先调大 repl-backlog-size 和优化网络，比盲目开无盘更有效。
