底层编码转换时机与调参

同一个 key 的 TYPE 从不改变，底层编码却会在数据量增长时悄悄从紧凑结构切换成通用结构，单条命令的复杂度与内存占用随之跳变。看 TYPE 判断性能是外行做法，看 OBJECT ENCODING 才是内行。本文以 Redis 7 为基准，实测每类编码的转换触发时机，讲清单向性、转换代价与调参方法。

一、编码决定命令的真实成本

Redis 对外的类型（TYPE）与内部编码（OBJECT ENCODING）是两层抽象。小数据量用紧凑编码：listpack 把元素连续存储，CPU 缓存友好、内存极致，但每次操作都要线性扫描；数据量超过阈值后切换成通用结构：hashtable 提供真正的 O(1) 查找，skiplist 支持范围查询与排名。这意味着：listpack 编码的 Hash 做点查也是 O(N)，只是 N 小时比 hashtable 的常数开销更低。判断"这个 key 的操作快不快、内存省不省"，第一件事是看编码。MEMORY USAGE 的结果同样由编码主导：元素个数相同的两个 key，编码不同内存可以差 3 到 5 倍。这也是同一业务模型在不同量级下表现突变的原因：字段从 100 涨到 200 的那一刻，Hash 静默转码，QPS 没变但 P99 抖动、内存跳涨，事后看监控只会发现"什么都没改却变慢了"，根因往往就是这条隐式转换。

二、实测：命令触发编码变化

String 有三段式编码，用 APPEND 就能观察到迁移：

127.0.0.1:6379> SET k 12345
OK
127.0.0.1:6379> OBJECT ENCODING k
"int"
127.0.0.1:6379> SET s short
OK
127.0.0.1:6379> OBJECT ENCODING s
"embstr"
127.0.0.1:6379> APPEND s " to make it longer than forty four bytes"
(integer) 42
127.0.0.1:6379> OBJECT ENCODING s
"raw"

容器类型的转换藏在写入命令里：HSET 第 129 个字段、或某个字段值超过 64 字节时，Hash 从 listpack 转 hashtable；ZADD 超过同样阈值后转 skiplist；Set 是三段式，全整数且个数不超过 set-max-intset-entries（默认 512）时是 intset，混入一个字符串成员就退出，再超限转 hashtable。容器实验各跑一遍就能建立直觉：

127.0.0.1:6379> ZADD zb 1 m
OK
127.0.0.1:6379> OBJECT ENCODING zb
"listpack"
127.0.0.1:6379> SADD si 1 2 3
(integer) 3
127.0.0.1:6379> OBJECT ENCODING si
"intset"
127.0.0.1:6379> SADD si hello
(integer) 1
127.0.0.1:6379> OBJECT ENCODING si
"listpack"

ZSet 同理：第 129 个成员或任何一个超 64 字节的 member，编码立刻变成 skiplist。

三、转换触发点与单向性

Redis 7 默认阈值汇总如下：

| 类型 | 紧凑编码 | 通用编码 | 转换触发点 |

| --- | --- | --- | --- |

| String | int / embstr | raw | 值超 44 字节，或被 APPEND/SETRANGE 修改 |

| List | quicklist（listpack 节点） | 同左，节点超限即分裂 | list-max-listpack-size，默认单节点 8 KB |

| Hash | listpack | hashtable | 字段数 > 128，或任一字段值 > 64 字节 |

| Set | intset / listpack | hashtable | 出现非整数成员，或个数/长度超限 |

| ZSet | listpack | skiplist | 成员数 > 128，或任一成员 > 64 字节 |

最关键的特性是转换单向：HDEL 把字段删回 100 个，编码仍是 hashtable，不会退回 listpack；ZSet、Set 同理。只有 DEL/EXPIRE 之后重建 key 才会复位。所以"曾经胖过"的 key 会永远带着通用编码的内存开销，靠删除内容给大 key 瘦身是无效操作。验证单向性只需三步：建一个 200 字段的 Hash 确认编码是 hashtable，HDEL 到只剩 3 个字段再看编码，依然是 hashtable；想真正回收内存，要么 UNLINK 后重建，要么迁移到新 key 再切流量。另一个细节是 embstr 被设计为只读，任何修改（APPEND、SETRANGE、INCRBYFLOAT 等）都会让它退化为 raw。

转换前后命令复杂度的对照记两条：listpack 编码的 HSET/HDEL 是 O(N)（N 为字段总数），转 hashtable 后变 O(1) 均摊；listpack 的 ZRANK 是线性扫描，转 skiplist 后是 O(log N)。所以转换既推高内存、也加速点查，"该不该避免转换"取决于读写比例——写一次、读千万次的大容器，转码是划算的。

四、转换的代价与调参

转换发生在触发它的那条写命令里，是同步的 O(N) 重建：几千字段的 Hash 在转 hashtable 的那一刻会出现一次延迟毛刺，这也是"小 key 慢慢长大"比"一次性写大"更容易出现超时的原因之一。转换完成后内存明显跳升——hashtable 每个条目要额外承担 dictEntry 指针与桶数组开销，而 listpack 是纯顺序存储，实测常有数倍差距。

调参思路按场景走：

1. 字段少、值短、只增不减的对象缓存，可以调大 hash-max-listpack-entries（如 256/512）换取更省的内存，但要意识到字段操作退化为 O(N)，先压测再上线。
2. 值普遍较长（如存 JSON 片段）的场景不要调参数。 hash-max-listpack-value 保持 64 即可，任何一个超长值都会让整体转码，调大 entries 阈值毫无意义。
3. 用 MEMORY USAGE key 量化真实内存，用 redis-cli --bigkeys 周期巡检各类型的最大元素个数，把编码异常的 key 揪出来。
4. 写路径避免反复试探。 整对象一次 HSET 写完优于逐字段追加，减少中间状态的转码次数。

一个真实调参案例：用户画像 Hash 固定 200 个字段、每个值都在 10 字节以内，默认 128 阈值让它常年处于 hashtable 编码。把 hash-max-listpack-entries 调到 256 后回到 listpack，单实例内存下降约三成；代价是 HGET 从 O(1) 变成 200 个字段的线性扫描，读路径压测无感知。反过来，字段数不可控的对象不要调，转码毛刺与扫描成本都会失控。变更管理上，这些阈值属于改完立即全局生效的重配置：变更前 CONFIG GET 留档、灰度实例先验证、错峰执行，并盯着 evicted_keys 与慢日志的变化，任何一项恶化立即回滚。

常见坑 / 最佳实践

1. 编码转换不可逆。 大 Hash 删字段不会退回 listpack，要释放内存只能迁移到新 key 后删除旧 key（用 UNLINK）。
2. APPEND 会把 int/embstr 打回 raw。 把 String 当日志追加、拼 URL 用的 key，内存增长比预期快，长文本考虑分片或压缩。
3. Set 混入一个字符串成员就退出 intset。 纯整数 ID 场景的写入方不要带 u: 之类前缀，编码退化后内存与判存性能双降。
4. 调大 listpack 阈值前先看值长度分布。 只要有一个值超过 max-listpack-value，整个容器照样转码，调参等于无效，还拉长了 O(N) 扫描。
5. 排查性能先看编码再下结论。 OBJECT ENCODING 显示 listpack 的大集合，点查也是线性扫描；显示 hashtable 的才适合高频点查。

小结

• TYPE 与编码是两层，命令的真实复杂度由 OBJECT ENCODING 决定，排查性能先看编码。
• 各类型在"元素个数超 128 / 单值超 64 字节 / 混入异构成员"时转换编码，String 的分界是 44 字节与修改操作。
• 转换是单向、同步、O(N) 的：删内容不回退编码，转码瞬间有延迟毛刺，内存数倍跳升。
• 调参要结合值长度分布，MEMORY USAGE 与 --bigkeys 是量化手段，写路径尽量整对象一次写入。