RDB文件远小于内存占用，因其采用类型编码优化和LZF压缩，剔除redisObject头、SDS元数据、过期时间等运行时开销，并对整数字符串、小哈希等做紧凑编码。
直接用 redis-cli --rdb + gzip -l 算最准
Redis RDB 文件本身是二进制快照，不带元数据压缩标记，所以不能靠 DEBUG OBJECT 或 MEMORY USAGE 估算——那些只反映运行时内存编码（如 ziplist、quicklist），和磁盘上 RDB 的压缩无关。真正能算出「备份数据压缩比」的，只有对 RDB 文件本身做外部压缩前后对比。
实操分三步：
- 用
redis-cli --rdb dump.rdb触发一次本地 RDB 快照（或从生产环境拷贝现成的.rdb文件） - 原始大小：直接
stat -c "%s" dump.rdb或ls -l dump.rdb - 压缩后大小：
gzip -k dump.rdb && gzip -l dump.rdb.gz，看compressed列数值
压缩比 = 原始大小 ÷ 压缩后大小。例如 120MB RDB 压缩成 32MB，比值就是 3.75。注意：RDB 默认不启用 LZF 压缩（rdbcompression yes 是开关，但算法固定为 LZF，不可换 LZ4/gzip），所以这个比值反映的是 Redis 自身序列化 + LZF 的效果，不是你用 Go 手动再压一遍的结果。
go-redis 客户端存字符串时，别拿 LEN 当压缩比依据
很多人用 redis.String(ctx, key) 拿值再 len()，然后和原始字符串比——这完全无效。原因有三：
立即学习“go语言免费学习笔记（深入）”；
- 如果服务端开了
compress-algorithm lz4，返回的是 LZ4 块，redis.String()会失败或乱码，根本读不到正确长度 - 即使没开服务端压缩，Go 客户端写入前自己 gzip 过，读回来解压后
len()得到的是原始长度，不是「Redis 存了多少字节」 - Redis 内部对小字符串用
embstr编码，大字符串转raw，这两者在MEMORY USAGE返回值里也不体现实际网络传输量
真要评估 Go 写入路径的压缩收益，必须抓包或打日志：在 redis.Client.Do() 前后记录 []byte 长度，才是你发出去的 payload 大小。
JSON/日志类数据用 compress/gzip 压缩前，先预估冗余度
不是所有字符串都值得 gzip。Go 里用 gzip.NewWriter 压一个 200B 的 JSON，结果可能更大——因为 gzip header 固定占 10+ 字节，且短文本找不到足够重复模式。
可快速判断是否该压：
- 原始字符串含大量重复字段名（如
"user_id":123,"user_name":"alice"）、空格缩进、换行符：大概率能压 30%～50% - 内容是 base64 图片、加密 token、Protobuf 序列化结果：gzip 后基本不变，甚至变大，纯耗 CPU
- 长度
len(s) ：直接跳过压缩，<code>redis-go对小值的网络开销几乎可忽略
代码里别写死 gzip.BestCompression。实测中 gzip.DefaultCompression 和 BestSpeed 在 JSON 场景下压缩率差距不到 5%，但 CPU 耗时差 3 倍以上。
服务端 LZ4 压缩生效，必须配全三项且重启连接
只改 compress-algorithm lz4 没用。Redis 6.0+ 的服务端压缩是独立模块，三个参数缺一不可：
-
compress-depth 1：设为 1 表示对所有新写入尝试压缩（0 = 关闭） -
compress-threads 2：至少设为 1，否则线程池不启动，压缩逻辑被跳过 -
compress-algorithm lz4：注意不是lz4hc，后者单次 CPU 耗时翻倍，不适合高并发写
改完必须 CONFIG REWRITE 并让 Go 客户端重建连接——旧连接收的仍是明文，新连接才能收到 LZ4 块。而且客户端读取时不能用 redis.String()，得走 redis.Bytes() + 手动 lz4.UncompressBlock()，否则直接 panic。
真正省的是网卡到 Go heap 这一段，不是 Redis 响应时间。如果业务经常只取 JSON 里的某个字段，全量解压反而更亏。
