redis 7.0 内存更省是因为 listpack 替代 ziplist 后使小对象内存布局更规整，降低 jemalloc 内部碎片，从而减少假性内存满和淘汰频率。
Redis 7.0 的内存更省，不是因为“变魔术”，而是 listpack 替代 ziplist 后，让小对象的内存布局更规整、更可预测，从而降低了 jemalloc 的内部碎片——这直接减少了因碎片导致的“假性内存满”，间接拉低了触发内存淘汰的频率。
为什么 listpack 能减少内存碎片，而不是单纯“少占几个字节”
关键不在总大小，而在分配模式是否匹配 jemalloc 的分桶逻辑。ziplist 每个 entry 带变长 prevlen 字段（1 或 5 字节），加上对齐填充，导致整体长度浮动大；listpack 用固定格式记录当前 entry 长度 + 绝对偏移数组，中小数据（如 16 字节字符串、int16）编码后长度高度集中（常见 17/19/21 字节）。jemalloc 能稳定复用 32 字节或 64 字节桶，不再被迫“升桶”浪费空间。
实测中，相同 1000 个 16 字节字符串：
• ziplist 内存占用浮动在 18–24KB，mem_fragmentation_ratio 达 1.6+；
• listpack 稳定在 ~16.5KB，mem_fragmentation_ratio 常压到 1.1–1.3。
这意味着：即使 maxmemory 设为 2GB，ziplist 下可能因碎片实际可用内存只剩 1.25GB 就触发淘汰；而 listpack 下能撑到接近 1.8GB 才真正告急。
listpack 不生效？检查这几个配置项是否把你“绕过”了
listpack 是默认启用的，但极易被配置或操作“绕开”。只要以下任一条件满足，Redis 就会退化为 quicklist（底层是双向链表+多个 listpack 节点）甚至 linkedlist，彻底失去紧凑优势：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
list-max-ziplist-size（实际控制listpack大小）设为负数（如-2），强制走quicklist -
hash-max-ziplist-entries或zset-max-ziplist-entries过小（如设成16），导致稍多一点数据就升级为hashtable/skiplist，不仅不省空间，还因结构切换产生外部碎片 - 高频混合操作：
LPOP+RPUSH在边界反复进出，触发多次realloc，把原本连续的listpack拆得七零八落
验证是否真正在用：DEBUG OBJECT key 返回 encoding: listpack 才算成功；若显示 quicklist 或 linkedlist，说明已退化。
淘汰频率下降 ≠ 可以忽略淘汰策略选型
碎片率降低，只是推迟了“内存告急”的时间点，并未改变淘汰策略本身的触发逻辑。当真实数据量持续增长，或设置了保守的 maxmemory，该淘汰还是得淘汰。
尤其注意：
• volatile-lru 和 allkeys-lru 在 listpack 场景下效果更明显——因为更多 key 能长期保持紧凑编码，LRU 信息更稳定；
• 但若大量 key 带 TTL 且集中过期，惰性删除 + 定期删除仍可能造成短时内存尖峰，listpack 救不了这个；
• allkeys-random 在 listpack 下反而可能更伤——随机删掉一个 listpack 节点，可能导致整个块无法复用，加剧外部碎片。
真正影响淘汰频率的，从来不是“用了什么结构”，而是“结构有没有被你用对”——listpack 很安静，但它只对规整的数据和克制的操作有反应；一旦你频繁修改、盲目调参、或混用大对象，它就默默退场，把问题还给 jemalloc 和淘汰策略。
