Redis 的常见数据结构有哪些？｜腾讯后端开发面经解析

60 秒回答模板

可以这样回答：Redis 常用对外数据结构包括 String、List、Hash、Set、ZSet、Bitmap、HyperLogLog、Geo 和 Stream。回答时还要区分对外类型和底层编码，例如 SDS、listpack、quicklist、dict、intset 和 skiplist。 String 基于 SDS 保存二进制安全字符串；Hash 小对象常用 listpack，规模变大后用 dict；List 由 quicklist/listpack 组织；Set 可用 intset 或 dict；ZSet 常用 dict 加 skiplist 同时支持按 member 查分数和按 score 排序范围查询；Stream 有消息 ID、consumer group 和 pending 机制。不同结构对应不同复杂度和内存成本。Hash 适合对象字段，Set 适合去重和集合运算，ZSet 适合排行榜和延迟队列，Stream 适合轻量消息流。big key、元素过多和编码升级都会影响延迟和内存。不要只列五种基本类型。面试官继续追问时常问底层编码、跳表为什么适合范围查询、Hash 什么时候转 dict、以及不同结构在 big key 场景下的风险。验证时重点看：看能否把类型、典型命令、复杂度、底层编码和业务场景对应起来，例如 ZSet 的 ZRANGE/ZRANGEBYSCORE、Set 的 SINTER、Hash 的 HGET/HMGET。

考点 考点边界

主线 核心机制

易错点 只列 String、List、Hash、Set、ZSe…

深入解析

考点边界

这题是 Redis 数据结构题，边界在每种类型适合的访问模式、复杂度、内存结构和编码转换，不是泛泛讲缓存一致性或 Redis 为什么快。本题对应“Redis 数据结构与底层编码”，核心前提是：Redis 常用对外数据结构包括 String、List、Hash、Set、ZSet、Bitmap、HyperLogLog、Geo 和 Stream。回答时还要区分对外类型和底层编码，例如 SDS、listpack、quicklist、dict、intset 和 skiplist。

核心机制

String 基于 SDS 保存二进制安全字符串；Hash 小对象常用 listpack，规模变大后用 dict；List 由 quicklist/listpack 组织；Set 可用 intset 或 dict；ZSet 常用 dict 加 skiplist 同时支持按 member 查分数和按 score 排序范围查询；Stream 有消息 ID、consumer group 和 pending 机制。关键证据要落到命令执行路径、数据结构编码、事件循环、复制状态，这样才能说明机制为什么能支撑题目结论。如果继续展开，要把命令、底层编码、事件循环、过期或复制状态放到同一条 Redis 执行链路里解释。

关键取舍

不同结构对应不同复杂度和内存成本。Hash 适合对象字段，Set 适合去重和集合运算，ZSet 适合排行榜和延迟队列，Stream 适合轻量消息流。big key、元素过多和编码升级都会影响延迟和内存。因此要同时看命令复杂度、内存占用、主线程阻塞、复制延迟和 failover 窗口，避免把 Redis 当成强一致数据库。这些取舍决定了方案在不同输入规模、延迟、内存、并发、泛化或一致性要求下是否仍然成立。

边界风险

不要只列五种基本类型。面试官继续追问时常问底层编码、跳表为什么适合范围查询、Hash 什么时候转 dict、以及不同结构在 big key 场景下的风险。排查时优先看 INFO、SLOWLOG、latency doctor、big key、hot key、过期统计、复制延迟和 failover 日志。需要特别关注极端输入、数据分布变化、资源不足、并发竞争或观测口径错误带来的退化。修复时要先确认慢在命令、数据结构、网络、过期、持久化还是复制切换，再决定拆 key、限流、改结构或调整高可用。

验证抓手

验证时看 INFO、SLOWLOG、latency doctor、命令耗时、big key/hot key、expired_keys、evicted_keys、复制 offset/lag、Sentinel/Cluster 日志、AOF/RDB 配置和业务回源 QPS。针对本题，最有价值的验证信号是：看能否把类型、典型命令、复杂度、底层编码和业务场景对应起来，例如 ZSet 的 ZRANGE/ZRANGEBYSCORE、Set 的 SINTER、Hash 的 HGET/HMGET。把验证抓手说出来，可以让答案从知识点延伸到Redis 命令行为、延迟和故障窗口验证。

易错点

只列 String、List、Hash、Set、ZSet，不讲底层编码、复杂度和适用场景。
把 Redis 数据结构题回答成缓存一致性或单线程模型，偏离题面。
把相邻概念混用，没有明确说明这道题真正考察的边界。
没有给出验证方式，导致答案听起来完整但无法判断是否真的生效。

面试官追问

ZSet 为什么常用跳表？

跳表按 score 有序，插入、删除和查找平均 O(log n)，同时天然支持范围遍历。Redis 还会配合 dict 做 member 到 score 的快速定位。

Redis 为什么会有不同底层编码？

小对象用紧凑编码可以省内存，元素变多后切到 dict、quicklist 或 skiplist 保证访问效率。编码选择是在内存占用和操作复杂度之间取舍。

“Redis 的常见数据结构有哪些”继续追问时最该补哪条边界？

应该围绕“Redis 数据结构与底层编码”补适用前提、失败场景和验证证据。先说明哪些条件下这个机制成立，再说明哪些输入规模、并发状态、数据分布或资源限制会让答案需要调整。

“Redis 的常见数据结构有哪些”怎样回答才不是只背概念？

看它能否把“Redis 数据结构与底层编码”的机制链路、关键取舍和可观测信号连起来。回答时应落到具体状态变化、数据路径、复杂度、指标或排查工具，而不是只复述定义。

Redis 题怎么区分数据结构、缓存和高可用三条线？

数据结构看类型、底层编码、复杂度和内存；缓存看命中率、过期、穿透击穿雪崩和回源；高可用看复制延迟、Sentinel/Cluster、failover 和丢数据窗口。