Redis RDB压缩开启后CPU飙升明显，是不是该关掉？

先说一个核心判断：如果业务对写入延迟敏感，或者实例负载已经偏高，那么rdbcompression yes这个配置项，很可能就是一个隐形的性能瓶颈。

原因在于RDB持久化的机制。当执行SA VE或BGSA VE时，fork出的子进程在完成数据序列化后，会调用LZF算法对整个dump.rdb文件进行一次全量压缩。注意，这不是边生成边压缩的流式处理，而是必须等内存中攒齐了整个数据快照之后，再一次性压缩。这种操作模式，很容易导致CPU使用率峰值翻倍，尤其是在内存容量较大（比如超过16GB）的实例上，效果会格外明显。

实际业务中，这通常表现为：BGSA VE执行期间，主进程响应明显变慢；通过INFO commandstats命令查看，会发现cmdstat_sa ve的耗时陡增；监控系统上则能看到used_cpu_sys_children指标持续走高。

如何判断当前 RDB 压缩是否真成了瓶颈？

别靠猜测，直接通过几个关键指标来验证：

首先，查看INFO persistence的输出，关注rdb_bgsa ve_in_progress和rdb_last_bgsa ve_status。这能帮你确认后台保存是否频繁失败或超时。

其次，对比INFO stats中的used_cpu_sys和used_cpu_sys_children。如果子进程的系统CPU占用超过了主进程的40%，并且这种高占用集中间出现在BGSA VE时段，那么压缩带来的开销就已经不容忽视了。

最后，一个更底层的观察方法是使用命令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并没有提供更灵活的压缩选项。Redis 6.0之后虽然支持了rdbchecksum，但压缩算法仍然是硬编码在源码rdb.c中的LZF，没有提供配置入口来切换成zstd或lz4这类更新、效率可能更高的算法。所谓的“分片压缩”也不现实，因为RDB是原子性的完整快照，无法被拆分成多个块进行并行压缩。

那么，可行的折中方案其实只有两个：

第一，调整持久化的触发频率。例如，将配置从sa ve 60 10000改为sa ve 300 10000，通过减少BGSA VE的触发次数，来间接降低压缩带来的CPU冲击。

第二，考虑改用AOF与RDB的混合持久化模式（配置aof-use-rdb-preamble yes）。在这种模式下，BGSA VE生成的RDB文件主要用于AOF重写的“前导”，而不是直接用于数据恢复。因此，你可以放心地关闭RDB压缩，而AOF重写过程中的压缩行为则由独立的bgrewriteaof流程控制，两者互不干扰。

说到底，RDB压缩本质上是一场资源交换：用CPU时间去换取磁盘空间和网络带宽。当业务写入压力激增时，这场交换很容易变得“亏本”。一个常常被忽略的细节是：即便一次BGSA VE仅仅多耗费了100毫秒，在高并发的场景下，这也可能让主进程错过几个关键的毫秒级响应窗口，从而影响整体服务的流畅性。