客户端压缩的取舍
客户端压缩指在应用侧先把 value 压缩，再整体写入 Redis。value 较大（几十 KB 以上）且访问频次中等时，省下的内存通常很可观，网络带宽也同步下降；高频读写的小对象压缩则往往得不偿失，因为每次读写都要付出编解码的 CPU 与额外延迟。压缩比与数据内容强相关，文本、JSON、日志类数据收益高，已压缩过的二进制数据几乎没有空间。
基本信息
| 收益区间 | 大 value、访问频次偏中低 |
|---|---|
| 主要成本 | 编解码 CPU 与单次请求延迟 |
| 内存收益 | 随压缩比变化，需实测 |
| 验证方式 | 对比压缩前后内存占用与 P99 延迟 |
| 兼容注意 | 值本身二进制安全，但要与序列化格式约定一致 |
| 观测命令 | MEMORY USAGE、STRLEN、GET 后统计长度 |
典型使用场景
- 大文档、报表类缓存占用内存过多，考虑压缩换取容量
- 跨机房传输量大，希望同时降低带宽与延迟
- 冷数据占比高，读频低但必须保留，适合压缩存储
- 评估在客户端缓存之上再加一层压缩的整体收益
- 为混合内容（文本加二进制）设计分类型压缩策略
- 压测验证压缩后的 CPU 与延迟开销是否可接受
- 实例内存预算紧张，先看非侵入式的压缩能省多少再谈扩容
- 统一多语言客户端的压缩格式约定，避免互相读不了数据
评估与验证
评估与验证
redis-cli MEMORY USAGE cache:doc:1 # 压缩前的实际占用
redis-cli STRLEN cache:doc:1 # 原始长度
redis-cli GET cache:doc:1 | wc -c # 导出长度做对照
printf '%s' "$(redis-cli GET cache:doc:1)" | gzip -c | wc -c # 粗算压缩比
redis-cli --memkeys -i 0.1 # 按内存排序列出大键
redis-cli INFO memory | grep -E 'used_memory:'压缩决策对照
| 数据特征 | 内存收益 | 是否推荐 |
|---|---|---|
| 文本、JSON、日志 | 高 | 推荐 |
| 已压缩的二进制 | 接近无 | 不推荐 |
| 热点小对象 | 低 | 不推荐 |
| 冷数据大对象 | 高 | 推荐 |
压缩比不要照抄经验值：用真实业务样本压一遍，再按内存单价与 CPU 成本算收益。
压缩后写入的是二进制，排查问题时用可视化工具看不到原文，调试与排障流程要预留解码手段。
压缩只改变单值的存储体积，不会减少键数量与键名开销；键名占比较大时，压缩的边际收益会被稀释。