Redis 五大核心数据类型底层原理

在后端开发大厂面试中，Redis 几乎是必问的技术栈，而 "说说 Redis 的核心数据类型及其应用场景、底层原理" 更是高频中的高频。

很多候选人只能答出基本 5 种类型和简单 K-V 使用，但一旦面试官追问：底层编码演进、Ziplist 级联更新缺陷、渐进式 Rehash、生产 BigKey 治理、List 与 Stream 消息队列差异等底层问题，基本都会翻车。

一、Redis 五大核心数据类型底层总览（Redis7.x 最新编码）

Redis 对外暴露 5 种核心数据类型，但底层会根据数据量大小、数据格式 自动适配不同的内存编码，极致平衡「内存占用」和「读写性能」。Redis7.x 最大更新：彻底废弃 Ziplist，全面升级 Listpack，解决经典级联更新卡顿问题。

外层数据类型	底层编码	底层物理结构	适用场景阈值	核心业务场景
String 字符串	int / embstr / raw	SDS 动态字符串	整数用int；≤44字节且非整数用embstr；>44字节用raw	分布式锁、计数器、Session、验证码、全局ID
Hash 哈希	listpack / hashtable	紧凑列表 / 字典（渐进式Rehash）	元素＜512、单值＜64字节用listpack，否则升级哈希表	用户信息、购物车、结构化对象缓存
List 列表	quicklist	双向链表+内嵌listpack	Redis3.2+ 固定结构，7.0+ 内部替换为listpack	时间线、动态流、简单消息队列、排队任务
Set 集合	intset / hashtable	整数有序数组 / 哈希字典	全整数、数量＜512用intset，否则升级哈希表	去重、共同好友、标签系统、UV统计、抽奖
ZSet 有序集合	listpack / skiplist+dict	紧凑列表 / 跳表+哈希表	元素≤128、单值＜64字节用listpack，否则升级跳表结构	热搜排行榜、延时队列、限流滑窗、权重排序

二、核心底层结构深度拆解

2.1 String 底层：SDS 动态字符串（为什么不用C原生字符串？）

Redis 完全抛弃 C 语言原生字符串，自研 SDS（Simple Dynamic String，简单动态字符串），是 Redis 高性能、高可靠的基石。

C原生字符串三大致命缺陷：

获取长度O(N) ：需要遍历字符串直到 \0 结束，高性能场景无法接受；
缓冲区溢出风险：拼接字符串需手动计算空间，极易内存溢出导致进程崩溃；
二进制不安全 ：以 \0 作为结束标识，无法存储图片、视频、压缩包等二进制数据。

SDS 核心优势：

O(1) 获取长度：结构体内置 len 字段，直接读取长度，无需遍历；
自动扩容、防溢出：修改数据前校验容量，自动预分配内存，杜绝缓冲区溢出；
二进制安全：依靠 len 字段界定数据边界，不依赖结束符，可存储任意二进制数据；
内存极致优化：提供 sdshdr5/8/16/32/64 多规格结构体，适配不同长度字符串，减少内存碎片。

SDS 简易结构：len(实际长度) + alloc(总容量) + flags(类型) + buf(数据缓冲区)

2.2 Hash/ZSet 重大升级：Ziplist 淘汰，Listpack 全面上位

Redis 旧版本中，Hash、ZSet 少量数据时使用 Ziplist 压缩列表 ，内存极度紧凑，但存在致命的级联更新问题，是生产卡顿的元凶。

Ziplist 致命缺陷：级联更新（Cascade Update）

Ziplist 每个节点会记录上一个节点的长度（prevlen）：前节点＜254字节，prevlen占1字节；超过254字节，prevlen占5字节。

当某个节点数据扩容、长度突破254字节时，后续所有节点的 prevlen 都需要重新扩容、重写，一处修改、全员联动，高并发写入下会阻塞主线程，造成接口卡顿。

Redis7.x 革命性升级：Listpack 紧凑数组

Listpack 彻底重构存储逻辑：不再记录上一个节点长度，而是将当前节点长度存在节点末尾。

核心优化：修改、插入、删除节点，仅影响当前节点，彻底消灭级联更新问题，同时保留 Ziplist 内存紧凑、低开销的优势，兼顾性能与内存。

2.3 ZSet 核心：为什么用跳表，不用红黑树？

ZSet 大数据量下底层为 HashTable + SkipList 跳表 复合结构：

HashTable：保证根据 member 查询 score 时间复杂度 O(1)；
SkipList：保证范围排序、区间查询 O(logN)。

大厂高频面试题：Redis 有序集合为什么用跳表，不用红黑树？

区间查询效率碾压红黑树：跳表找到区间起点后，可通过底层链表直接遍历取值，无回溯开销；红黑树区间查询需要多次遍历、回溯节点，逻辑复杂、性能差。
实现简单、维护成本低：跳表仅需修改指针指向；红黑树需要变色、左旋、右旋，平衡逻辑极其复杂。
并发友好：跳表增删改仅局部指针变更，锁粒度小；红黑树平衡调整会牵动多层节点，并发控制难度极大。

2.4 List 底层：Quicklist 快慢平衡设计

普通双向链表指针开销大、内存碎片化严重；纯紧凑数组增删扩容开销极高。Redis 3.2+ 推出 Quicklist 快速列表，完美折中两者优缺点。

结构：双向链表 + 内嵌 Listpack

原理：链表的每个节点不再是单一数据，而是一个连续内存的 Listpack 数组。通过配置控制每个节点元素数量，既享受连续内存的缓存命中率，又规避大数组整体扩容拷贝的性能问题，完美适配消息队列、时间线场景。

三、大厂高频面试真题突击

真题1：Redis Hash 渐进式 Rehash 如何实现？为什么不会卡顿？

面试满分回答：

Redis 字典包含两个哈希表 ht $0$ 、ht $1$ ，常态下仅使用 ht $0$ 。当哈希表负载过高需要扩容时，不会一次性全量迁移（阻塞主线程），而是采用渐进式 Rehash。

初始化：为 ht $1$ 分配翻倍空间，开启 rehash 标识；
随写随迁：后续每一次增删改查操作，都会顺带迁移 ht $0$ 中 rehashidx 对应槽位的数据到 ht $1$ ，并递进索引；
定时兜底：无业务操作时，后台定时任务分批迁移数据，保证进度不停滞；
读写兼容：新增数据全部写入 ht $1$ ；查询先查 ht $0$ ，无结果再查 ht $1$ ；
收尾置换：ht $0$ 数据全部迁移完成后，回收 ht $0$ 空间，完成 Rehash。

核心优势：将一次性海量 IO 拆分到无数次操作中，零阻塞、无卡顿，适配 Redis 单线程模型。

真题2：Set 类型底层升降级规则是什么？

面试满分回答：

Set 存在两种底层编码：intset 整数集合 和 hashtable 哈希表。

初始化存入纯整数、数量≤512时，使用 intset（有序连续数组，二分查找 O(logN)，极度省内存）。

满足以下任意条件，不可逆升级为 hashtable：

元素数量超过默认阈值 512；
存入非整数类型数据（字符串、特殊字符）。

升级后不可逆、不会自动降级，即便后续删除非整数数据、减少元素数量，仍会保留hashtable编码，避免频繁升降级带来的性能损耗，保证数据结构统一，维持 O(1) 极致读写性能。

真题3：如何用 List 模拟栈、队列、阻塞消息队列？

面试满分回答：

模拟栈（FILO 先进后出）：LPUSH + LPOP / RPUSH + RPOP，同端进出；
模拟队列（FIFO 先进先出）：LPUSH + RPOP / RPUSH + LPOP，一端入、对端出；
阻塞消息队列：LPUSH + BRPOP。队列为空时消费者阻塞等待，不循环轮询空跑，节省 CPU 资源，有消息立即唤醒消费。

真题4：生产 BigKey 有什么危害？如何治理？

面试满分回答：

BigKey 核心危害（单线程致命问题）：

主线程阻塞：大 Key 读写、删除时间复杂度 O(N)，单线程串行执行，阻塞所有业务请求；
集群数据倾斜：大 Key 独占分片内存，导致节点内存爆满、触发淘汰策略；
网络 IO 打满：超大 Key 传输会占满网卡带宽，引发延迟、丢包；
过期删除卡顿：大 Key 过期释放内存，阻塞主线程。

生产级治理方案（完整版）：

Key 拆分（核心方案）：将大 Hash/ZSet 按用户ID、时间、分片规则拆分为多个小 Key，规避单Key数据量过大问题；
禁用全量遍历命令：生产环境严禁 HGETALL、SMEMBERS、ZRANGE 全量读取，统一替换为 HSCAN/SSCAN/ZSCAN 游标分批遍历，渐进式读取数据，避免单次IO阻塞；
开启懒删除机制 ：Redis4.0+ 支持 Lazy Free，使用 UNLINK 替代 DEL，将大Key内存释放交由后台异步线程处理，完全不阻塞主线程；同时可配置 lazyfree-lazy-user-del yes 全局默认懒删除；
严控写入阈值：业务层限制单Hash字段数、单ZSet元素数量，提前拦截大Key生成；
监控巡检告警：定时扫描集群大Key、热Key，对超标Key提前优化、拆分，规避线上故障。

真题5：List 能做 MQ，为什么 Redis5.0 还要推出 Stream？

面试满分回答：

List 模拟消息队列属于极简方案，存在三大致命短板，无法用于生产可靠消息投递：

无 ACK 确认机制：消息被 BRPOP 取出后直接从 Redis 删除，消费者宕机、网络异常会导致消息永久丢失；
不支持多消费者组：一条消息只能被一个消费者消费，无法实现一对多广播、多业务独立消费；
无消息回溯能力：消费完成即删除，无法查询、回放历史消息。

Stream 完美解决所有痛点 ：借鉴 Kafka 设计，支持消费者组、消息持久化、PEL 未确认队列、XACK 手动确认，消息未确认可重试消费，支持历史消息回溯，是 Redis 官方主推的生产级轻量消息队列。同时 Stream 支持消息持久化、消息ID有序自增、故障重试机制，完全满足业务可靠投递需求，彻底碾压 List 简易MQ方案。

四、全文总结（面试升华话术）

Redis 五大数据类型的底层设计，核心思想只有一个：极致的工程取舍。

SDS 解决了高性能字符串读写问题，Listpack 彻底根治级联更新卡顿，Quicklist 平衡内存与性能，跳表适配有序区间查询，渐进式 Rehash 适配单线程无阻塞扩容。

真正的面试高分，不是背会命令，而是理解每种数据结构的设计权衡、适配场景、版本迭代优化、生产缺陷与落地优化方案，这也是初级开发和高级架构师的核心差距。吃透本文Redis7.2+新版底层特性、高频面试真题，可从容应对99%的Redis数据结构相关面试追问。