Redis 7.0+ 默认启用 rdbcompression yes 和 rdbchecksum yes；前者启用zlib压缩（仅字符串有效，增CPU 10%~30%，减文件30%~60%），后者添加CRC64校验（增文件约1%，防静默错误）；二者修改后必须重启生效，CONFIG SET 无效。
redis.conf里rdbcompression和rdbchecksum怎么设
Redis 7.0+ 默认启用 rdbcompression yes（zlib）和 rdbchecksum yes，但这两个开关不是“开就完事”，它们直接影响 fork 后子进程的 CPU 消耗和 RDB 文件体积。压缩本身不减少内存占用，只影响磁盘写入阶段的 CPU 时间和最终 dump.rdb 大小。
-
rdbcompression yes：启用 zlib 压缩（仅对字符串类型有效，hash/set/zset 等结构不压缩）；CPU 占用会上升 10%~30%，文件体积通常减小 30%~60% -
rdbcompression no：禁用压缩，fork 子进程几乎不额外消耗 CPU，但dump.rdb可能大 2~3 倍，尤其当大量短字符串 key 存在时 -
rdbchecksum yes：在 RDB 文件末尾写入 CRC64 校验码，加载时校验；增加约 1% 文件大小，但避免因磁盘静默错误导致加载崩溃 -
rdbchecksum no：跳过校验，加载略快，但遇到损坏的 RDB 文件会直接 abort，而不是报错提示
什么时候该关掉rdbcompression
不是所有场景都适合压缩。当你的 Redis 实例内存占用高（比如 >8GB）、BGSAVE 频繁（如 save 60 10000），且磁盘空间充足时，关掉压缩反而更稳。
- 典型高风险场景：实例内存 12GB，每分钟触发一次 BGSAVE → fork + 压缩可能让子进程卡住主线程 200ms+，P99 延迟毛刺明显
- 推荐关闭条件：磁盘 I/O 不是瓶颈、备份文件走对象存储（按量计费，空间成本低）、业务能容忍稍大文件
- 别只看 CPU 使用率：top 里看不到压缩开销，它藏在
bgrewriteaof或save进程的 CPU time 里，得用pidstat -p $(pgrep redis) 1观察
zlib压缩级别无法手动调，但有替代方案
Redis 内置 zlib 压缩固定用 level 1（最快），不支持配置成 level 6 或 9。所以想“压得更狠”或“压得更轻”都不行 —— 这不是配置项缺失，是 Redis 故意限制的权衡。
- 如果你真需要更高压缩率：只能在备份后用外部工具处理，例如
gzip -1 dump.rdb（仍用 level 1，但覆盖全文件）或zstd -T1 dump.rdb - 但注意：Redis 加载时只认原生
dump.rdb，外部压缩后的文件不能直接被redis-server读取 - 真正影响恢复速度的是 RDB 文件解压阶段：
rdbcompression yes时，加载也要解压，比不压缩慢 10%~15%，尤其在低配机器上
混合持久化下rdbcompression还起作用吗
起作用，但只作用于混合模式里的 RDB 基础部分。Redis 3.0+ 的 aof-use-rdb-preamble yes 会让 AOF 文件开头嵌一个 RDB 快照，这个嵌入段依然受 rdbcompression 控制。
- 也就是说：即使你开了 AOF，只要启用了混合模式，RDB 压缩设置依然生效
- 验证方式：停机后检查
appendonly.aof文件头，用xxd -l 128 appendonly.aof，如果看到RDB\0\0\0\0\0\0\0\0后紧跟着非 ASCII 字节，说明开头那段被压缩了 - 别误以为“开了 AOF 就不用管 RDB 设置”——混合模式本质是 RDB + AOF 的拼接，两套参数各自独立生效
最容易被忽略的一点：压缩开关改完必须重启 Redis 才生效，CONFIG SET rdbcompression yes 是无效命令。很多运维在线改配置后没验证，结果发现新生成的 dump.rdb 大小没变，其实是没重启服务。
