开启repl-diskless-sync yes仅跳过主节点RDB落盘，必须配对repl-diskless-sync-delay（建议5–10秒）和client-output-buffer-limit slave（如256mb 64mb 60），否则易致CPU飙升、从库断连或缓冲区溢出；日志无“RDB saved on disk”才表明真正启用无盘路径。
直接开 repl-diskless-sync yes 并不能自动解决磁盘 IO 高的问题——它只在主节点真正发起全量同步时跳过落盘，但前提是必须配对 repl-diskless-sync-delay 和 client-output-buffer-limit slave，否则可能引发 CPU 爆涨、从库断连或缓冲区溢出。
为什么开了 repl-diskless-sync yes 还有磁盘 IO
常见错误是只改了开关，没确认实际是否走无盘路径。Redis 日志里如果出现 Background saving started by pid XXX 但后续**没有** RDB saved on disk 提示，才说明走的是无盘流；如果看到 DB saved on disk，说明仍走传统磁盘复制——repl-diskless-sync 没生效，大概率是配置没 reload 或写在了错误的 conf 文件里。
- 检查是否真的启用：
redis-cli CONFIG GET repl-diskless-sync返回"yes"才算生效 - 配置必须写在主节点的
redis.conf中，且需CONFIG REWRITE或重启加载 - 从节点配置无关，该参数仅作用于主节点
- 若主节点内存使用率 >70%，即使开了无盘，
fork()开销仍会导致主线程卡顿，IO 看似下降但响应延迟飙升
repl-diskless-sync-delay 设多少才合理
这个值不是“越大越好”，也不是“越小越快”，而是平衡 fork 次数与从库等待时间的防抖阈值。默认 0 表示来一个从库就 fork 一次，10 个从库同时重连 = 10 次 fork，瞬间拉满 CPU。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生产建议设为
5～10：能有效聚合多数场景下的同步请求，又不明显拖慢首批从库恢复 - 别设
0：除非你确定永远只有 1 个从库，且不允许任何延迟 - 别设 >
30：从库repl-timeout默认是 60 秒，等太久容易触发超时断连，反而重试更多次 - 设为
5后，观察INFO replication中master_repl_offset是否稳定增长，避免长时间卡在wait_bgsave
必须同步调整的两个关键配套参数
单独开无盘复制，不调缓冲区和积压区，等于给高速路修了快车道，却忘了清障车和收费站——网络一抖，全堵死。
-
client-output-buffer-limit slave必须显式设置，例如：client-output-buffer-limit slave 256mb 64mb 60（256MB 硬上限，64MB 持续 60 秒触发断连）——防止从库失联时主节点无限缓存命令，吃光内存 -
repl-backlog-size建议至少128mb起，按写入量估算：比如每秒写入 3MB，希望撑住 60 秒断连，就设180mb以上；否则等待期间 backlog 溢出，本可增量同步的也退化成全量，白开无盘 - 修改
repl-backlog-size后 Redis 会重建缓冲区，但旧数据不清除，确保内存余量充足再改
无盘复制不解决但常被误认的问题
很多人看到主库磁盘 IO 下降，就以为“所有负载都降了”，其实不然。无盘复制只绕过主节点 RDB 落盘，其他瓶颈照旧存在。
- 它不缓解
fork()的 COW 内存拷贝压力——大内存实例仍可能卡主线程几百毫秒 - 它不解决从库失联后
repl-backlog持续膨胀的内存问题，那得靠repl-timeout+client-output-buffer-limit主动清理连接 - 它不降低网络带宽消耗，RDB 流大小和原来一样，只是不经过磁盘中转
- 它对增量同步（PSYNC）完全无影响，
repl-diskless-sync只参与全量阶段
真正要压住主库负载，得把 repl-diskless-sync yes、repl-diskless-sync-delay、client-output-buffer-limit slave、repl-backlog-size 四个参数当成一个组合来调，漏掉任意一个，都可能让优化效果打折扣甚至引发新问题。
