无盘复制解决了传统主从全量同步中主节点 fork+磁盘写入和从节点落盘加载的双重IO瓶颈；它跳过主节点落盘，由子进程直接通过socket发送RDB流，规避磁盘寻道与IO竞争。
无盘复制到底解决了什么瓶颈
传统主从全量同步时，主节点必须先执行 bgsave，把整个数据集写到磁盘生成 RDB 文件，再读取该文件、通过网络发给从节点。这个过程卡在两个地方：一是 fork 子进程 + 磁盘顺序写（尤其机械盘或高负载 SSD），二是从节点收到后还得落盘再加载——两头都等 IO。
而 repl-diskless-sync yes 的核心作用，是跳过「主节点落盘」这一步：RDB 数据不写磁盘，而是由子进程直接通过 socket 写入网络连接，从节点边收边解析加载。它规避的不是网络带宽，而是磁盘寻道（平均 8–10ms）和 IO 队列竞争。
常见错误现象：
- 主节点 CPU 不高，但
INFO replication显示master_repl_offset滞后严重，slave0:state=wait_bgsave - 全量同步耗时 >30 秒，且
redis-cli --stat显示瞬时 output_kbps 突然归零几秒，之后才冲高 - 日志里反复出现
Background saving started by pid XXX，但没看到RDB saved on disk提示（说明走的是无盘路径）
怎么开、开在哪、哪些参数必须配对
repl-diskless-sync 是开关，但单独打开没用，必须配合延迟启动和缓冲区控制：
-
repl-diskless-sync yes：启用无盘模式（默认no） -
repl-diskless-sync-delay 5：等待最多 5 秒，看是否有其他从节点同时请求同步；有就合并发送，省一次 fork（建议 5–10，别设 0） -
client-output-buffer-limit slave 1024mb 512mb 60：主节点内存缓冲区上限要够大，否则一卡就断连（默认是 256mb，高内存实例务必调高）
注意：从节点不需要改任何配置，所有逻辑都在主节点侧完成。
容易踩的坑：
- 开了
repl-diskless-sync yes却没调client-output-buffer-limit→ 从节点接收慢时主节点 OOM kill - 把
repl-diskless-sync-delay设成 0 → 失去批量优化，反而增加 fork 频次 - 在低内存机器（<4GB）上盲目开 1GB 缓冲 → 挤占 Redis 自身内存，触发频繁 swap
什么时候不该开无盘复制
无盘复制不是银弹，它把 IO 压力转成了内存和网络压力。以下场景慎用或禁用：
- 主节点内存紧张（可用内存 < 数据集大小 × 1.5）→ RDB 流式生成期间需额外内存暂存压缩数据
- 网络不稳定或跨机房部署（如主在北京、从在新加坡）→ 无盘传输一旦中断就得重来，而有盘模式可断点续传（RDB 文件已存在）
- 启用了 AOF 且
aof-use-rdb-preamble yes（混合持久化）→ 此时主节点仍会先落 RDB 盘，无盘失效 - 从节点磁盘极快、内存极小（如嵌入式设备）→ 宁可让从节点多扛点 IO，也别让主节点爆内存
性能影响实测参考（2025 年末主流云环境）：
- 同机房、32GB 数据集、万兆网：开启后全量同步时间从 42s → 19s，主节点峰值内存增加 1.2GB
- 跨可用区、16GB 数据集、千兆网：开启后失败率上升至 17%，建议关掉并调大
repl-timeout
验证是否真走无盘路径
不能只看配置，得看运行时行为：
- 登录主节点执行
redis-cli info replication，观察loading字段：若为1且持续十几秒，大概率是无盘流式加载（有盘模式 loading 通常只在从节点出现） - 查看主节点日志：
Sync with slave XXX done前没有RDB saved on disk记录，基本确认走无盘 - 用
strace -p $(pgrep redis-server) -e trace=write,sendto 2>&1 | grep -E "(sendto|write).+socket"抓包（生产慎用），能看到大量小块 socket 写入，而非单次大 write 到 .rdb 文件
最容易被忽略的一点：无盘复制只作用于全量同步，不影响增量同步（PSYNC）。如果从节点频繁断线重连，真正拖慢体验的可能是 repl_backlog_size 太小导致被迫降级为全量——这时候光开无盘没用，得一起调大积压缓冲区。
