ziplist 与 listpack 的交替
Redis 7.0 把小集合的紧凑编码从 ziplist 换成 listpack：hash、zset、list 在小数据量下不再返回 ziplist，OBJECT ENCODING 会显示 listpack，对应的配置项也从 *-max-ziplist-* 改名为 *-max-listpack-*。旧配置文件里的旧参数名在新版本不生效（启动时对未知参数会有告警），阈值会静默回到默认值，这是升级后内存表现发生变化的常见原因。编码类型还直接影响单键内存开销，升级评估不能只看阈值数字相同就认为表现一致。
基本信息
| 变化版本 | Redis 7.0 起 |
|---|---|
| 影响类型 | hash / zset / list |
| hash 改名 | hash-max-ziplist-entries 变为 hash-max-listpack-entries |
| zset 改名 | zset-max-ziplist-* 变为 zset-max-listpack-* |
| list 改名 | list-max-ziplist-size 变为 list-max-listpack-size |
| 编码标识 | OBJECT ENCODING 返回 listpack |
| 核对方式 | 升级后用 CONFIG GET 验证生效值 |
升级清单里的核对项
- 配置文件中的旧参数名是否已替换，未替换的阈值等于回默认
- 业务是否依赖 OBJECT ENCODING 的返回值，监控脚本与测试断言常踩
- 压测与容量结论是否基于旧编码，需要重跑关键场景
- 哨兵、集群与运维脚本中是否有硬编码的旧配置项名
- 升级后一周内对比 used_memory 与键数增长曲线，确认无异常抬升
- 回滚预案要写清楚：配置项名变化意味着回滚时参数得改回来
- 升级后重新校准内存水位告警，编码变化会改变曲线形状
- 确认客户端驱动版本能正确解析新版本返回的字段，避免解析缺失被误判为故障
核对生效值
核对生效值
redis-cli INFO server | grep -E 'redis_version' # 先确认版本
redis-cli CONFIG GET hash-max-listpack-entries # 7.0 起的新名称
redis-cli CONFIG GET hash-max-ziplist-entries # 旧名在新版本无返回
redis-cli CONFIG GET zset-max-listpack-entries
redis-cli CONFIG GET list-max-listpack-size
redis-cli OBJECT ENCODING myhash # 期望看到 listpack
redis-cli MEMORY USAGE myhash # 对比同规模键的开销变化
redis-cli DBSIZE # 结合键数看总量曲线编码与参数对照
| 旧版本 | 7.0 起 | 影响 |
|---|---|---|
| ziplist | listpack | OBJECT ENCODING 返回值变化 |
| hash-max-ziplist-entries | hash-max-listpack-entries | 阈值未改名则不生效 |
| zset-max-ziplist-value | zset-max-listpack-value | 大成员判定阈值 |
| list-max-ziplist-size | list-max-listpack-size | quicklist 节点容量 |
listpack 与 ziplist 的内存占用与比较方式都不同，阈值一致不代表内存表现一致，升级评估要重跑真实数据样本。
旧客户端与运维脚本一般不关心编码名，但断言编码、按编码估算内存的脚本要一起改动，否则会得到错误结论。
集群或哨兵场景下逐节点核对参数比抽查一台可靠：滚动升级期间新旧版本与新旧配置会短暂并存。