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