开启repl-diskless-sync能加速主从初始化，但若repl-diskless-sync-delay设为0或过小、client-output-buffer-limit slave未同步调大，会导致主节点瞬间fork多个子进程，引发CPU飙升和内存OOM。
开启 repl-diskless-sync 能显著加快主从初始化，但默认配置下几乎必然引发主节点 CPU 或内存雪崩——关键不在“开不开”，而在怎么配、配多大、配给谁。
为什么无盘复制反而导致主节点 OOM 或 CPU 打满？
无盘复制跳过 RDB 落盘，由子进程直接压缩并流式发送数据到从节点 socket。这省掉了磁盘 IO，但所有待发送的 RDB 流都堆在主节点内存里，且每来一个 SYNC 请求就可能 fork 一个新子进程。
- 若
repl-diskless-sync-delay设为 0 或 1，多个从节点几乎同时发起同步时，主节点会瞬间 fork 出 5～10 个子进程，CPU 瞬间飙高，内存拷贝翻倍 - 若
client-output-buffer-limit slave仍用默认值（256mb 64mb 60），一旦某个从节点接收慢（网络抖动、自身 load 高），缓冲区溢出就会触发断连 → 重试 → 再 fork → 更多内存占用 → OOM 杀进程 - 跨机房场景下，TCP 传输中断无法断点续传，失败后只能重来，进一步放大上述问题
repl-diskless-sync-delay 应该设多少？
这个参数是主节点对多个 SYNC 请求的“攒批窗口”，不是越小越好，也不是越大越稳。
- 从节点少（2～5 台）：设为
10，平衡响应延迟与 fork 频率 - 从节点多（10+ 台）或部署分散：设为
20～30，确保多数请求被合并 - 必须配合
INFO REPLICATION观察：master_repl_offset和各slaveX:offset差值是否在 delay 窗口内稳定收敛；若差值长期不缩小，说明没真正攒上 - 若发现
repl-backlog-histlen长期接近repl-backlog-size，说明攒批期间积压命令太多，需同步加大repl-backlog-size
client-output-buffer-limit slave 必须同步调大
无盘模式下，RDB 数据全程走内存 + socket，不再有磁盘暂存兜底。缓冲区限制必须按实际带宽和最差网络状况预估。
- 典型错误：开了
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 倍余量（例如设为 1GB），否则 fork + 缓冲区双吃内存，OOM 概率极高 - 跨机房（如主在北京、从在新加坡）慎用：网络抖动导致传输中断，无法像有盘模式那样从 RDB 文件断点续传
真正卡住人的从来不是“要不要开无盘”，而是 repl-diskless-sync-delay 和 client-output-buffer-limit slave 这两个参数的联动节奏——它们必须一起调、一起压测、一起监控，缺一不可。
