rdb文件在主从复制中是否压缩仅由rdbcompression控制，它决定落盘时是否用lzf压缩，而非网络传输压缩；传输是原样发送已生成的rdb文件，无实时流式压缩；真正影响传输效率的是repl-diskless-sync配置。
Redis 5.0 主从复制本身不支持网络传输层的压缩，RDB 文件在发送前是否被压缩，只取决于 rdbcompression 配置项 —— 它控制的是 RDB 文件**落盘时是否用 LZF 压缩**，而非网络传输过程中的压缩。
为什么 rdbcompression yes 不等于“传输压缩”
这个配置影响的是主节点执行 bgsave 生成的 dump.rdb 文件大小：设为 yes 时，RDB 文件体积更小，但加载时需解压，CPU 开销略高；设为 no 则文件更大、传输耗时可能增加，但节省 CPU。
关键点在于：无论 rdbcompression 如何设置，主节点都是把整个 RDB 文件（已写入磁盘的二进制块）通过 TCP socket 原样发给从节点，中间没有额外的流式压缩/解压环节。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点不会对 socket 发送的数据做 gzip/LZ4 等实时压缩
- 从节点也不会对接收的字节流做解压，它直接把收到的字节写入临时 RDB 文件，再加载
- 所以网络带宽占用 ≈
du -b dump.rdb的大小（启用压缩时更小，否则更大）
repl-diskless-sync 与传输效率的关系
真正影响传输阶段效率的，是是否启用无盘同步（diskless replication），由 repl-diskless-sync 控制：
- 设为
yes：主节点bgsave后不写磁盘，而是直接把 RDB 数据通过 pipe 推给 socket，避免磁盘 I/O 和双倍拷贝 - 设为
no（默认）：先写dump.rdb到磁盘，再读取该文件发给从节点，多一次磁盘读 - 注意：
repl-diskless-sync和rdbcompression是正交配置，可同时开启，但 diskless 模式下rdbcompression仍生效 —— 因为 bgsave 过程照常压缩
容易被忽略的兼容性细节
diskless 模式依赖 repl-diskless-sync-delay 和内核 pipe buffer 行为，在某些低内存或高延迟网络下可能触发超时或连接中断：
-
repl-diskless-sync-delay 5表示等待最多 5 秒，攒多个从节点一起发，减少 fork 次数 - 若从节点在 delay 期间断连，会重试，但主节点日志里只报
Connection reset by peer，不易定位 - Linux 内核 fs.pipe-max-size
真正需要压缩传输的场景（比如跨公网同步），得靠外部手段：走 SSH 隧道、用 socat 套一层 gzip stream、或者前置 nginx 做代理压缩 —— Redis 协议本身不提供该能力。
