redis主从复制中，全量同步的rdb文件传输不支持原生压缩，仅能通过外部代理或tc限速缓解；增量同步自7.0起支持repl-compress yes（需编译含lz4），但主从须同时启用且消耗cpu；客户端侧压缩最灵活但需业务适配；稳定复制需tc限速、repl-compress、大key治理与backlog合理配置四者联动。

Redis 主从复制过程中的网络传输压缩，不能靠“一键开启”，得按阶段拆解——**全量同步**和**增量同步**的压缩机制完全不同，且原生支持有限，很多压缩必须靠外部配合或客户端介入。

全量同步：RDB 文件传输无法被 Redis 原生压缩

主节点生成 RDB 快照后，会以原始二进制形式直接通过 TCP 发送给从节点。Redis 不支持对 RDB 文件本身做 LZ4/ZSTD 等算法压缩，即使你启用了 repl-diskless-sync yes（免磁盘同步），也只是跳过写本地文件这步，数据流仍是明文、未压缩的。

真正能起作用的只有两种方式：

• 用 tc 在主节点出向网卡限速（如限 50Mbit），避免突发大 RDB 打满带宽；这不是压缩，但能稳住链路
• 在中间加代理层（如自研 proxy 或支持压缩的 Redis 网关），在发送前对 RDB 流做 LZ4 压缩——Redis 服务端不参与，纯外部处理

增量同步：repl-backlog 中的命令流可启用 LZ4 压缩

从 Redis 7.0 开始，支持配置 repl-compress yes（需编译时链接 LZ4 库）。它只对增量复制中发送的 repl backlog 命令流 做压缩，不影响 RDB。

启用前提和注意事项：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 编译 Redis 时必须带上 --with-lz4，否则该参数无效
• 主从节点都要启用，否则解压失败导致同步中断
• 压缩/解压消耗 CPU，小规格实例（如 2C4G）可能反而拖慢同步速度
• 对单个大 Key 的命令（如 HMSET big_hash ...）压缩效果有限，仍可能瞬间占满带宽

客户端侧压缩：最灵活、也最常用

如果业务允许，把压缩逻辑下沉到应用层，是最可控的方式：

• PHP 使用 phpredis ≥6.3.0，配置 redis.compression = 1，自动对所有读写 payload 做 zlib 压缩
• Python 可用 redis-py 配合 lz4 或 zstd 库，在 set()/get() 前后手动压缩解压
• Java 用 Lettuce 或 Jedis，集成 Zstd-JNI 等库实现透明压缩

这种方式不依赖 Redis 版本，也不影响主从协议，但要求业务代码适配，且压缩/解压开销由客户端承担。

别忽略大 Key 和 backlog 配置的协同作用

再好的压缩或限速，遇上一个 50MB 的 HASH，照样会冲垮链路。所以必须配套治理：

• 用 redis-cli --bigkeys 或 MEMORY USAGE 定期扫描大 Key，分批拆分或改用流式结构
• repl-backlog-size 要设够——比如主库写入 2MB/s、容忍断连 90 秒，至少设为 200mb（留 10% 余量）
• repl-timeout 要同步调大（如设为 120），否则限速或压缩带来的延迟容易触发超时重连

真正稳住复制流量，靠的是 tc 限速 + repl-compress + 大 Key 治理 + backlog 合理配置 四者联动，缺一不可。