redis常见数据结构及其编码方式

1.引言

提到 Redis 的数据结构，多数人会立刻想到 String、Hash、List 等常用类型。但鲜有人知的是：Redis 在底层实现时，并不会严格绑定某一种数据结构 —— 为了兼顾性能与空间效率，它会根据数据的实际特征动态选择 “编码方式”。这种 “表面类型与底层编码分离” 的设计，正是 Redis 能在复杂场景下保持高效的核心原因之一。本文将带你拆解 Redis 数据结构的编码优化逻辑，看懂 “数据结构背后的真相”。

2.常见数据结构

当前版本的redis支持10个数据类型，其中5个比较常用

3.核心认知：数据类型与编码方式的 “分离设计”

3.1 复杂度不变，实现动态适配

Redis 的设计坚守一个基本原则：无论底层采用何种编码，用户操作数据结构的时间复杂度、空间复杂度都与抽象类型承诺一致。

例如，Hash 类型对外承诺 “键值对的增删改查为 O (1)”，底层无论用 “压缩列表” 还是 “哈希表” 实现，都能保证这一复杂度；但两种编码的空间占用、操作效率在不同数据规模下差异巨大 —— 这正是编码优化的价值所在。

3.2 编码方式的 “切换触发条件”

编码方式的切换由 Redis 自动完成，无需用户干预，触发条件通常与 “数据量大小” 或 “元素特征” 相关：

• 小数据量场景：优先选择 “空间紧凑” 的编码（如压缩列表），节省内存；
• 大数据量 / 高频操作场景：自动切换到 “操作高效” 的编码（如哈希表、跳表），保证性能。

这种 “自适应切换” 让 Redis 既能高效存储海量小数据，又能应对大数据的高频访问，实现 “内存与性能的平衡”。

4.查看底层编码 ——object encoding

要验证 Redis 的编码优化逻辑，最直接的方式是使用object encoding命令 —— 它能返回指定 Key 对应的 Value 的实际底层编码。

• 语法：object encoding key
  

5. 常用数据类型的编码优化逻辑

5.1 String（字符串）:3 种编码适配不同场景

String 是 Redis 最基础的类型，底层支持 3 种编码，核心围绕 “字符串长度” 与 “是否可修改” 优化：

编码类型	适用场景	核心优势
int	字符串为 64 位以内的整数（如set num 123）	直接用整数存储，比字符串格式更省内存
embstr	字符串长度≤44 字节（默认）的短字符串	字符串与 Redis 对象元数据存储在同一块内存，减少内存碎片
raw	字符串长度 > 44 字节的长字符串	单独存储字符串内容，避免元数据与长字符串占用连续内

示例：

127.0.0.1:6379> set num 123456
OK
127.0.0.1:6379> object encoding num
"int"  # 整数编码127.0.0.1:6379> set short_str "hello redis"  # 11字节
OK
127.0.0.1:6379> object encoding short_str
"embstr"  # 短字符串编码127.0.0.1:6379> set long_str "this is a very long string...(超过44字节)"
OK
127.0.0.1:6379> object encoding long_str
"raw"  # 长字符串编码

5.2 Hash（哈希）：压缩列表 vs 哈希表

Hash 用于存储 “键值对集合”，编码切换的核心是 “键值对数量” 与 “元素大小”：

编码类型	适用场景	核心优势
ziplist（压缩列表）	键值对数量≤512 个（默认），且每个键 / 值长度≤64 字节	连续内存存储，无哈希表的指针开销，极省内存
hashtable（哈希表）	键值对数量 > 512 个，或任一键 / 值长度 > 64 字节	支持 O (1) 的增删改查，适合高

• 优化逻辑：小哈希表用压缩列表节省内存（如存储用户基本信息，字段少且短）；当数据增长后，自动切换到哈希表保证操作效率（如存储商品的多维度属性，字段多且长）。

5.3 List（列表）：压缩列表 vs 双向链表

List 是 “有序元素集合”，编码优化围绕 “元素数量” 与 “长度”：

编码类型	适用场景	核心优势
ziplist（压缩列表）	元素数量≤512 个（默认），且每个元素长度≤64 字节	连续内存存储，遍历效率高，内存占用少
linkedlist（双向链表）	元素数量 > 512 个，或任一元素长度 > 64 字节	支持高效的头部 / 尾部插入删除，适合大列表

• 注意：Redis 3.2 版本后引入quicklist（快速列表）编码，它是 “压缩列表 + 双向链表” 的混合结构 ——
  将大列表拆分为多个小压缩列表，既保留压缩列表的内存优势，又解决长列表的遍历效率问题，目前已成为 List 的默认编码。

5.4 Set（集合）：整数集合 vs 哈希表

Set 是 “无序、唯一元素集合”，编码优化针对 “元素是否为整数”：

编码类型	适用场景	核心优势
intset（整数集合）	所有元素均为 64 位以内的整数（如sadd nums 1 2 3）	按整数大小有序存储，支持二分查找，内存占用极低
hashtable（哈希表）	包含非整数元素（如add names zhangsan lisi）	用哈希表的键存储集合元素（值为 null），支持 O (1) 的存在性判断

5.5 ZSet（有序集合）：压缩列表 vs 跳表

ZSet 是 “按分数排序的唯一元素集合”，编码优化围绕 “元素数量” 与 “长度”：

编码类型	适用场景	核心优势
ziplist（压缩列表）	元素数量≤128 个（默认），且每个元素长度≤64 字节	按分数有序存储，连续内存，省空间
skiplist（跳表）	元素数量 > 128 个，或任一元素长度 > 64 字节	结合跳表与哈希表，支持 O (logN) 的排序与查找，适合大数据排序场景（如排行榜）

6.小结

Redis 的数据结构设计，藏着 “平衡取舍” 的工程智慧：对外提供简单统一的抽象类型，让开发者无需关心底层细节；对内通过动态编码优化，在不同场景下实现 “内存与性能的最优解”。

核心要点可归纳为三点：

1. 分离设计：数据类型是 “抽象接口”，编码方式是 “底层实现”，复杂度承诺不变，实现动态适配；
2. 工具关键：object encoding命令是窥探底层的窗口，建议在开发调试时多使用，建立 “类型 - 编码” 的对应认知；
3. 场景适配：小数据用 “紧凑编码”（压缩列表、整数集合）省内存，大数据用 “高效编码”（哈希表、跳表）保性能，切换由 Redis 自动完成。