rdbcompression yes 有用但效果有限，LZF 压缩仅对重复字符串、空值等有效，对随机二进制或已压缩数据基本无效，典型压缩率30%–60%，且仅启动时生效。

Redis RDB 文件太大，rdbcompression yes 真的有用吗

有用，但效果取决于数据特征。LZF 压缩对重复字符串、空值、小整数等敏感，而对随机二进制、已压缩的 value（如 gzip 后的 JSON）、长唯一字符串基本无效，甚至可能略微增大体积。

实操建议：

• rdbcompression yes 是默认开启的，不用手动加；如果关了，RDB 会明显变大，尤其存大量 SET 或 HSET 的文本类数据时
• 不要指望它把 2GB 的 RDB 压到 200MB——通常压缩率在 30%–60%，视数据重复度而定
• 验证是否生效：停机后对比 dump.rdb 和 dump.rdb.bak（关闭压缩后生成）大小，或用 file dump.rdb 看是否含 LZF 字样

为什么开了 rdbcompression yes，RDB 还是没变小

常见原因是 value 本身已高度熵化，比如：

• 存了 base64 编码的图片、PDF 片段
• JSON 字段里每个 value 都带时间戳、UUID、加密 token
• 使用了 SET 存 protobuf / msgpack 序列化结果

这类数据 LZF 几乎无法压缩，反而因压缩头开销略增体积。此时更有效的是从源头控制：

• 避免在 Redis 存大 Value，改用文件系统 + key 指向路径
• 用 zstd 或 lz4 替代 LZF？不行——Redis 5.0+ 固死用 LZF，不支持换算法
• 检查是否误启用了 appendonly yes，AOF 文件可能比 RDB 更大，混淆判断

rdbcompression no 会导致什么实际问题

主要影响磁盘和网络 IO，不是功能缺陷：

• RDB 备份传输慢：1GB 未压缩文件比 400MB 压缩文件多传 600MB
• 磁盘空间紧张时，SAVE 或 BGSAVE 可能失败，报错 Cannot allocate memory（因写入临时文件需双倍空间）
• 主从全量同步耗时增加，从节点加载 RDB 时间变长
• 注意：rdbcompression no 不影响 AOF，AOF 永远不压缩

压缩开关在哪配、配错会怎样

只在 redis.conf 里配，位置靠近 dbfilename 和 dir：

dbfilename dump.rdb
dir /var/lib/redis
rdbcompression yes

错误配置示例及后果：

• 写成 rdb_compression yes（下划线）→ 启动忽略该行，按默认 yes 生效，但日志报 Unknown configuration parameter
• 写在 include 引入的子配置末尾 → 被后续同名配置覆盖，以最后出现为准
• 用 CONFIG SET rdbcompression no 动态修改 → 不生效，该参数仅在启动时读取，运行中不可改

真正影响体积的从来不是这个开关本身，而是你往 Redis 里塞了什么。压缩只是补救，设计才是关键。