【Redis】 五大基础数据类型 底层原理深度解析

大家好，我是程序员二叉。

简介

本文深度剖析 Redis 最核心的 5 种基础数据类型：String、List、Hash、Set、ZSet。
不仅讲解它们的底层数据结构实现，还揭秘设计原理、优缺点、以及为什么要这么设计，是面试和进阶必备的硬核知识。欢迎点赞关注收藏。

一、String 类型：底层结构、最大容量、使用场景

1. 底层结构：SDS (Simple Dynamic String)

Redis 没有直接使用 C 语言原生字符串，而是自定义了 SDS 动态字符串结构。

• 结构组成：len(已用长度) + alloc(总容量) + flags(类型) + buf(字节数组)
• 对比 C 字符串优势：
  1. O(1) 获取长度：无需遍历，直接读取 len 属性。
  2. 杜绝缓冲区溢出：修改前先检查容量，不足则自动扩容。
  3. 减少内存重分配：空间预分配 + 惰性空间释放，优化修改性能。
  4. 二进制安全：能存图片、视频等二进制数据。

2. 最大容量

• 单个 String 类型的Value 最大存储容量为 512MB。
• 注意：生产环境尽量避免使用超过 10KB 的大 Key，防止网络阻塞。

3. 核心使用场景

• 缓存对象（JSON 序列化）
• 分布式锁
• 计数器（INCR命令）
• 接口限流
• 分布式 Session

二、List 类型：底层 QuickList 原理

1. 底层结构：QuickList（快速链表）

Redis 3.2 之后，List 底层完全由 QuickList 实现，是经典的「双向链表 + 压缩列表」结合体。

2. QuickList 原理

• 整体结构：双向链表，每个节点是一个ziplist（压缩列表）。
• 设计思想：
  • 双向链表保证头尾操作极快（O(1)）。
  • 压缩列表保证内存紧凑、占用小。
• 节点存储规则：
  • 一个 quicklistNode 里会放多个元素。
  • 元素数量/大小达到阈值，就分裂新节点。
• 优点：
  • 比纯双向链表更省内存。
  • 比纯压缩列表修改效率更高。

一句话总结：QuickList = 双向链表保证性能 + ziplist 压缩节省内存。

三、Hash 类型：底层结构、为什么适合存对象

1. 底层结构（两种编码）

1. ziplist（压缩列表）：元素少、值小的时候使用。
2. hashtable（字典/哈希表）：数量多、值大时自动转换。
   • 结构类似 Java 的HashMap，数组 + 链表。
   • 哈希冲突用链地址法解决。

2. 为什么 Hash 最适合存储对象？

• 结构天然匹配：key -> {field:value, field:value}，完美对应对象结构。
• 修改效率极高：
  • 存 String 需要整个对象序列化/反序列化。
  • 存 Hash 可以单独修改某个字段（如只改用户名不改密码）。
• 内存更省：元素少时使用 ziplist，内存布局连续紧凑。
• 查询更快：O(1) 复杂度获取对象的任意属性。

3. 最佳实践

用户信息、商品详情、配置信息等结构化对象优先用 Hash。

四、Set 类型：底层、特点、应用场景

1. 底层结构

1. intset（整数集合）：元素全是整数且数量少时使用。
2. hashtable（字典）：元素多或非整数时使用。
   • 用字典的 key 存元素，value 统一为 null。

2. 核心特点

• 无序
• 不可重复
• 支持集合运算（交集、并集、差集）
• 增删查 O(1) 复杂度

3. 经典应用场景

• 好友/关注/粉丝关系
• 共同好友、共同关注（交集）
• 随机抽奖（SRANDMEMBER）
• 数据去重
• 独立访客 UV 标记

五、ZSet 类型：跳表 Skiplist 原理、为什么不用红黑树

1. 底层结构

ZSet =哈希表（O(1)查值） + 跳表（O(logn)排序/范围查询）

• 哈希表：存member->score，快速查分值。
• 跳表：存score->member，做排序、范围查询。

2. 跳表 Skiplist 原理

跳表是多层有序链表，通过建立多级索引实现二分查找效果。

• 每层都是有序链表。
• 最底层包含全部数据。
• 上层是下层的索引，查询时从顶层往下跳。
• 时间复杂度 O(logN)，效率接近平衡树。

简单理解：链表 + 多级索引 = 跳表。

3. 为什么用跳表，不用红黑树？

这是 Redis 最经典面试题，核心原因如下：

1. 范围查询更快更简单

   • ZSet 经常做ZRANGE范围查询。
   • 跳表范围查询只需找到起点，直接向后遍历。
   • 红黑树做范围查询复杂很多。

2. 实现更简单、代码更易维护

   • 跳表代码只有红黑树的1/3。
   • 调试、修改、扩展更安全。

3. 高并发下更高效

   • 跳表修改只需操作局部节点。
   • 红黑树需要频繁旋转平衡，开销更大。

4. 速度完全够用

   • 跳表 O(logN)，红黑树 O(logN)。
   • 实际性能差距极小，跳表优势更大。

结论：
跳表实现简单、范围查询强、效率足够高，完全满足 ZSet 需求，因此 Redis 选择跳表而不是红黑树。

总结

1. String：基于 SDS，最大 512MB，用于缓存、计数、分布式锁。
2. List：基于 QuickList（双向链表+ziplist），头尾极快、内存紧凑。
3. Hash：基于 ziplist + hashtable，最适合存对象，支持单字段修改。
4. Set：基于 intset + hashtable，去重、集合运算、随机抽取。
5. ZSet：基于跳表 + 哈希表，排序性能强；跳表比红黑树实现简单、范围查询更强。