Redis集群不处理小文件，RDB压缩是单节点操作；每个主节点独立生成并压缩dump.rdb，仅支持内置LZF压缩，高率压缩需备份后用zstd等外部工具完成。
Redis集群本身不直接处理小文件，压缩RDB是单节点操作
Redis集群（Cluster）只负责数据分片、故障转移和请求路由，它不感知、也不参与RDB文件的生成或压缩。RDB快照由每个主节点独立触发，save 或 bgsave 命令产生的 dump.rdb 是单机本地文件。所谓“大量小文件”如果指业务中存了海量 SET key value（value 很小），那集群只是把它们分散到不同节点——但每个节点落盘仍是单个 RDB 文件，不是多个小文件。
真正能压缩的是这个单节点 RDB 文件本身：
-
rdbcompression yes（默认开启）：启用 LZF 压缩，仅压缩 value，不压缩 key 和协议头，压缩率有限但几乎无 CPU 开销 -
rdbchecksum yes（默认开启）：校验和会略微增大文件，但不应关闭 - 若需更高压缩率（如备份归档），应在
bgsave完成后，用外部工具对dump.rdb重新压缩，例如：gzip -9 /var/lib/redis/dump.rdb
，得到dump.rdb.gz
为什么不能在 RDB 生成时直接用 gzip？
因为 bgsave 进程内部只支持 LZF（硬编码在 Redis 源码中），不调用系统 gzip 或 zstd。强行替换二进制或 patch 源码不仅破坏可维护性，还会导致：
- 子进程 fork 后若执行外部命令，可能因环境变量、PATH 或权限失败，使 RDB 写入中断
- 压缩耗时变长，延长
bgsave时间，增加 COW 内存占用，甚至触发 OOM - 集群节点间 RDB 格式必须严格一致，自定义压缩格式会让
CLUSTER NODES或故障恢复失效
备份链路中压缩该放在哪一环？
压缩应作为备份流程的后置步骤，而非侵入 Redis 运行时。典型安全做法：
- 配置
save 300 10等策略，确保 RDB 按需生成 - 用
redis-cli --rdb /tmp/dump.rdb主动拉取（避免依赖本地磁盘路径） - 传输完成后，在备份服务器上执行：
zstd -T0 /tmp/dump.rdb -o /backup/redis-$(date +%F).rdb.zst
（zstd比gzip压缩率高、解压快，且支持多线程） - 删除原始
.rdb，保留压缩包，并校验：zstd -t /backup/redis-2024-06-15.rdb.zst
注意：不要在 Redis 本机跑重压缩，尤其内存紧张时，zstd -T0 可能吃光所有 CPU 和内存，拖慢主进程。
小文件场景真正的瓶颈往往不在 RDB 大小
如果你观察到备份存储增长快，先确认是否真由 RDB 引起——更常见的情况是：
- RDB 频繁生成（如每秒
save 1 1），导致磁盘写满，而非单个文件大 - AOF 持久化开启且未重写，
appendonly.aof持续追加，体积远超 RDB - 集群有大量空闲 slot 或过期 key 未清理，RDB 中仍包含已逻辑删除但未落地的数据（可通过
redis-cli --bigkeys和MEMORY USAGE排查）
压缩 RDB 最多省 30%~50% 空间；而关掉冗余 AOF、调整 save 频率、定期 BGREWRITEAOF，常能降本 80% 以上。别让压缩成了掩盖配置失当的遮羞布。
