启用无盘复制、rdb channel和禁用从库持久化可显著提升redis主从同步性能。具体包括：redis 6.0+通过repl-diskless-sync跳过rdb落盘；8.0引入rdb channel实现rdb与命令流并行传输；从库需禁用rdb/aof加载以避免启动阻塞；配合lz4压缩进一步降低网络负载。
启用无盘复制避免磁盘IO瓶颈
传统全量同步要先写RDB到磁盘，再读取发送，两次磁盘IO在机械盘或高负载机器上极易成为瓶颈。Redis 6.0+ 支持 repl-diskless-sync，让主节点的 bgsave 进程直接把RDB流式发给从节点，跳过落盘环节。
必须在主节点配置：
repl-diskless-sync yes-
repl-diskless-sync-delay 5（等待最多5秒，合并多个从节点请求，提升带宽利用率）
注意：repl-diskless-sync-delay 不是越小越好——设为0会立即触发，但可能错过其他同期连接；设为5是生产环境较稳妥的平衡点。
升级到Redis 8.0开启RDB Channel Replication
即使开了无盘复制，RDB传输和命令流仍共用一个连接，主进程要协调转发，CPU和套接字开销仍存在。Redis 8.0 引入 RDB Channel，把RDB文件走独立连接传输，命令流走主通道，二者完全并行。
生效前提：
- 主从都运行 Redis 8.0+
- 从节点连接时主动声明支持：
rdb-channel-replcapability - 主节点无需额外配置，检测到能力后自动启用
+RDBCHANNELSYNC
实测显示：1GB数据同步耗时可降低30%~40%，主节点 top 中的 %CPU 尖峰明显平滑。
从库启动时不加载本地RDB文件
从库重启慢，往往不是同步慢，而是它自己加载残留RDB卡住主线程。哪怕RDB只有200MB，在低IO机器上也可能阻塞40秒以上，期间无法响应 INFO replication 或握手请求。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键操作是三禁一清：
-
save ""（清空所有自动快照规则） -
appendonly no（关AOF，不是appendfsync no） -
auto-aof-rewrite-percentage 0（防后台重写意外激活AOF） - 手动删除从库数据目录下的
dump.rdb和appendonly.aof
确认生效：启动后执行 redis-cli info persistence | grep loading，返回 loading:0 才算真正跳过加载。
压缩传输减少网络负载
RDB本身不压缩，但Redis支持在socket层启用LZ4压缩（需编译时开启--enable-lz4）。对文本类缓存（如JSON、HTML片段）效果显著，通常能压到原大小的40%~60%。
启用方式（主节点）：
-
repl-compress-rdb yes（仅对RDB启用，不影响命令流） - 确保从节点也支持LZ4（Redis 7.0+ 默认内置）
注意：压缩有CPU开销，如果主节点CPU已超70%，慎开；纯数值型数据（如计数器）压缩率极低，收益不大。
真正卡住RDB同步的，往往不是带宽或CPU，而是磁盘IO路径和从库自身的加载逻辑。无盘复制、RDB Channel、禁用从库持久化这三项叠加，基本能覆盖95%以上的慢同步场景。别忘了每次改配置后验证 INFO replication 的 master_sync_in_progress 和 loading 字段——眼见为实。
