是的，应关闭RDB压缩；开启后子进程全量LZF压缩会导致CPU翻倍、主进程响应变慢，尤其大内存实例；关掉仅增大2–5倍磁盘占用，安全可行，除非带宽受限或从节点启用replica-serve-stale-data no。
Redis RDB压缩开启后CPU飙升明显，是不是该关掉？
是的，如果业务对写入延迟敏感、实例负载已较高，rdbcompression yes 很可能成为隐性瓶颈。RDB save 过程中，fork 出的子进程在序列化完数据后，会用 LZF 算法对整个 dump.rdb 文件做一次全量压缩——这不是流式压缩，而是内存中攒完整个数据快照后再压，峰值 CPU 使用率容易翻倍，尤其在大内存实例（>16GB）上更明显。
常见现象包括：SAVE 或 BGSAVE 执行期间主进程响应变慢、INFO commandstats 中 cmdstat_save 耗时陡增、监控看到 used_cpu_sys_children 持续走高。
如何判断当前 RDB 压缩是否真成了瓶颈？
别猜，直接查三个关键指标：
-
INFO persistence中看rdb_bgsave_in_progress和rdb_last_bgsave_status，确认是否频繁失败或超时 -
INFO stats中对比used_cpu_sys和used_cpu_sys_children：若后者占前者 40% 以上，且集中在BGSAVE时段，压缩开销已不可忽视 - 用
strace -p $(pgrep redis-server) -e trace=clone,wait4,write观察子进程行为——如果看到大量clone后紧接长时间write，大概率卡在压缩写盘环节
关掉压缩（rdbcompression no）会影响什么？
影响只有两个：磁盘空间和网络传输成本。RDB 文件体积通常增大 2–5 倍（取决于数据结构，string 类型膨胀小，hash/list 等嵌套结构膨胀大），但 Redis 本身不关心这个——它只管读取时能否正确解码。只要磁盘够、备份同步不卡顿，rdbcompression no 是完全安全的。
注意两个例外场景必须保留压缩：
- 使用
redis-cli --rdb做远程 dump 到本地，带宽受限时压缩能显著缩短传输时间 - 启用
replica-serve-stale-data no且从节点频繁全量同步，未压缩 RDB 可能让从节点加载时间过长，触发连接超时
有没有折中方案？比如换压缩算法或分片压缩？
Redis 6.0+ 之后支持 rdbchecksum yes（默认开启），但不支持切换压缩算法——LZF 是硬编码在 rdb.c 里的，没有 zstd 或 lz4 的配置入口。所谓“分片压缩”也不存在，RDB 是原子快照，无法拆成块并行压。
真正可行的折中只有两个：
- 调低
save频率，例如从save 60 10000改成save 300 10000，减少压缩触发次数 - 改用 AOF + RDB 混合持久化（
aof-use-rdb-preamble yes），此时 BGSAVE 生成的 RDB 不用于恢复，可放心关压缩，AOF 重写时的压缩由bgrewriteaof控制，逻辑独立
RDB 压缩这件事，本质是用 CPU 换磁盘和带宽。业务写入压力一大，这个交换就容易亏本——很多人忽略的是，哪怕只多花 100ms 完成一次 BGSAVE，也可能让主进程在高并发下丢掉几个毫秒级的响应窗口。
