序列化方案怎么影响内存
同样的数据结构，用 JSON、MessagePack、Protobuf 存储时体积差异可观：文本格式可读、便于排查，但字段名与标点都占空间；二进制格式更紧凑，代价是人工排查变难。压缩能进一步缩小体积，但只有数据量超过一定规模后收益才明显，且增加编解码的 CPU 成本。
基本信息
| 文本序列化 | JSON 这类，可读性最好、体积最大 |
|---|---|
| 二进制序列化 | MessagePack、Protobuf 这类，紧凑但不能直接阅读 |
| 压缩 | LZ4、zstd、gzip 等，进一步省内存但吃 CPU |
| 判断顺序 | 先测体积，再算 CPU 与可维护性成本 |
| 观测方式 | MEMORY USAGE 看总开销，STRLEN 看值本身 |
方案取舍
| 方案 | 体积 | 适用场景 |
|---|---|---|
| JSON 等文本 | 大 | 需要人工排查、结构经常变化的配置类数据 |
| 二进制序列化 | 小 | 高频访问、结构稳定的大规模数据 |
| 压缩后存储 | 最小 | 体积大、读取频率不高的数据 |
| 字段化存储 | 取决于字段数量 | 需要按字段更新时，用哈希结构避免整值重写 |
测量与改法
测量与改法
redis-cli MEMORY USAGE user:1001 # 单键总开销，含对象头与键名
redis-cli STRLEN user:1001 # 值本身占用的字节数
redis-cli TYPE user:1001 # 先确定类型再谈改写方案
redis-cli MEMORY USAGE user:1001 | awk -F: '{print $2}' # 便于脚本批量采集
redis-cli --bigkeys # 找出体积突出的键作为优化对象典型使用场景
- 大 value 优化：先定位体积最大的那批键，再做定向改造
- 读写放大明显的场景：换紧凑格式降低网络与内存双重压力
- 缓存与持久化双重受限：压缩可以在两者上同时受益
- 结构频繁变更的数据：保留文本格式便于排查与回溯
- 压测对比：用同一批数据对比不同格式的体积与 CPU 开销
优化前先测量：小对象上编解码的 CPU 成本占比很高，省下的内存可能不值；优先处理体积最大的那批键，而不是全量换格式。
换格式意味着读写两端同时升级，需要兼容期与回滚方案；可以先按键前缀灰度，读路径同时兼容新旧两种格式。