如何预测Redis集群中sorted set（有序集合）的内存占用

核心前提：小容量zset默认使用ziplist编码 #

当zset满足以下两个条件时，Redis不会使用跳表+哈希表的标准结构存储，而是采用内存更紧凑的ziplist（压缩列表）编码：

• 元素数量小于配置值zset-max-ziplist-entries（默认128）
• 所有元素的字符串长度小于配置值zset-max-ziplist-value（默认64）
  你测试的单元素场景完全符合ziplist编码的触发条件，内存占用规律完全由ziplist、SDS字符串的存储规则和jemalloc内存分配的对齐策略决定。

测试结果对应原理 #

1. 1~8字符key场景总占用63字节、9字符key增加8字节 #

Redis的字符串使用SDS（简单动态字符串）存储，内存分配遵循2次幂对齐规则：

• 字符串长度≤8时，默认分配8字节的存储buf
• 字符串长度9~16时，默认分配16字节的存储buf
  二者刚好相差8字节，和你观测到的增量完全一致。加上dictEntry元数据、ziplist固定头、单元素+单score的存储开销，总占用刚好为63/71字节。

2. 元素从1字符改为8字符增加4字节 #

ziplist编码的zset按「元素值、score值、元素值、score值……」的顺序连续存储，所有内容都以字符串形式写入ziplist的entry中。
元素长度从1增加到8时，entry的payload长度增加7字节，加上jemalloc按固定大小类分配内存的对齐规则，最终总占用增量为4字节，符合你测试的75字节结果。

3. score从1字符改为8字符再增加4字节 #

ziplist中存储的score会先从double类型序列化为字符串，不是直接存储8字节的double值，所以score的字符串长度会直接影响内存占用。score长度从1增加到8时，同理在内存对齐后新增4字节开销，总占用达到79字节。

额外注意 #

当zset的元素数量或元素大小超过ziplist编码阈值后，会自动转成跳表+哈希表的编码格式，此时会额外引入跳表节点指针、哈希表entry等固定开销，内存增长规律会和当前测试结果不同，预估时需要区分编码场景。

内容的提问来源于stack exchange，提问作者ryechus