--- tags: [test/review, redis, data-structures, sds, quicklist, skiplist] create time: 2026-08-09 12:00 --- # Redis 五大核心数据结构_测试题 ## 概述 本测试覆盖 Redis 五种核心数据结构的底层实现原理，包括 SDS、quicklist、hash编码切换、intset/hashtable 切换以及 skiplist + hashtable 的 ZSet 结构。共 10 道题：6 道选择题、3 道填空题、1 道简答题。 --- ## 一、选择题（6道，由浅入深） > **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景 ### Q1（基础）— 考察定义层面 Redis String 类型底层使用 SDS（Simple Dynamic String）而非 C 字符串。以下哪一项**不是** SDS 相比 C 字符串的核心优势？ A. O(1) 获取字符串长度 B. 二进制安全，不会因为 \0 截断 C. 支持自动缩容以释放多余内存 D. 修改字符串时通过 free 字段实现惰性空间释放 ### Q2（基础）— 考察行为判断 对于一个 Hash 类型的键，在 Redis 4.0+ 中，当满足什么条件时会从 ziplist 切换到 hashtable 编码？ A. 元素数量超过 512 或者任意 value 长度超过 64 字节 B. 元素数量超过 1000 C. 任意 key 长度超过 64 字节 D. Hash 中包含浮点数类型的 value ### Q3（进阶）— 考察核心原理 Redis List 从 3.2 版本起统一使用 quicklist 实现。关于 quicklist 的结构特点，以下说法正确的是： A. quicklist 是一个双向链表，每个节点本身是一个独立的 linkedlist B. quicklist 的每个节点是 ziplist（或 listpack），通过 list-max-ziplist-size 控制节点大小 C. quicklist 只能单向遍历，无法支持 LPUSH 和 RPUSH 的组合操作 D. quicklist 的节点大小固定为 4KB，不支持动态调整 ### Q4（进阶）— 考察对比辨析 关于 Set 类型的 intset 和 hashtable 两种编码，以下哪项描述是正确的？ A. intset 可以存储字符串，但 hashtable 只能存储整数 B. intset 升级到达到的最大整数格式为 int64_t，且不可降级 C. 当 Set 中包含混合类型（整数 + 字符串）时，Redis 会同时使用 intset 和 hashtable D. intset 查找时间复杂度为 O(N)，hashtable 平均为 O(1) ### Q5（深入）— 考察场景推理 某电商系统使用 ZSet 实现商品销量排行榜，zadd score member 其中 score 为销量数值。随着商品数量从几十增长到数百万，ZSet 内部编码发生了什么变化？这种变化的根本原因是什么？ A. 从 hashtable 切换到 skiplist，因为 hashtable 不够灵活 B. 从 quicklist 切换到 ziplist，因为数据量增大后 ziplist 更高效 C. 从 quicklist 切换到 skiplist + hashtable，因为 skiplist 提供 O(log N) 的有序访问而 hashtable 提供 O(1) 的成员查找 D. 编码保持不变，始终使用 skiplist + hashtable，因为 Redis 会自动优化 ### Q6（深入）— 考察源码级别细节 Redis 7.0 引入了一项针对小字符串的内存优化：SDS_TYPE_5 直接存储在 dictEntry 的键槽中。这项优化的主要目的是什么？ A. 减少字符串比较的时间复杂度 B. 完全避免额外堆分配，降低内存碎片和 malloc 开销 C. 使短字符串可以使用更大的 maxlevel=64 来提升跳表性能 D. 让 SDS 兼容 C 字符串协议以便与旧版客户端通信 --- ## 二、填空题（3道） ### F1 — 填空 Redis ZSet 的内部实现组合了两种数据结构：跳表用于按 score 排序，______ 用于按 member 做 O(1) 查找。 > **提示**: 思考 ZSet 需要同时支持"按分数范围查询"和"精确成员查询"两个维度。 ### F2 — 填空 对于 quicklist，如果将 `list-max-ziplist-size` 设置为 **-2**，则表示每节点最大不超过 ______ KB。 > **提示**: 回顾表格中负数取值的含义。 ### F3 — 填空 Hash 类型在 Redis 4.0 之前使用 zipmap，4.0~5.x 使用 ziplist。默认切换到 hashtable 的条件是：元素数量大于 512 或任意 value 长度超过 ______ 字节。 > **提示**: 这是 Redis 对压缩列表上限的一个关键阈值。 --- ## 三、简答题（1道） ### S1 一个社交应用的点赞功能需要同时满足以下需求： 1. 统计每个用户的点赞总数（类似 `user_id:like_count`） 2. 维护一个用户点赞过的所有帖子 ID 列表（类似 `user:1:liked_posts`） 3. 对帖子维护一个被点赞用户列表，并按点赞时间排序 请结合 Redis 五大核心数据结构的特点，说明你会如何选择数据结构来存储以上信息？为什么不用其他替代方案？ > **答题框架提示**: > 1. 逐一对应三个业务需求选择最合适的结构 > 2. 考虑每种结构的编码切换策略 > 3. 分析替代方案的缺陷（如用 List 维护排序的代价） --- ## 参考答案与解析 ### 选择题答案 | 题号 | 正确答案 | 解析 | |------|---------|------| | Q1 | C | SDS 不支持自动缩容，只通过 free 字段保留空闲空间供下次复用。这是设计取舍——频繁缩容反而浪费 CPU。其他选项均为 SDS 核心优势：len 字段 O(1) 获得长度、记录 len 而非依赖 \0 实现二进制安全、free 实现惰性空间释放。 | | Q2 | A | Redis 4.0+ 的 Hash 哈希表切换条件是：有一个 value > 64 字节或元素数 > 512。注意 Redis 4.0 已将 ziplist 作为 Hash 编码废弃，默认用 hashtable。 | | Q3 | B | quicklist 是双向链表，每节点为 ziplist（Redis 7.0+ 为 listpack）。通过 list-max-ziplist-size 控制每节点规模。A 错在节点是 ziplist 而非 linkedlist；C 错在支持两端操作；D 错在可配置。 | | Q4 | B | intset 升级路径是 int16_t → int32_t → int64_t，一旦扩容 realloc 整个结构且不可降级。A 反了；C 不存在混存机制，非整数出现就全部转为 hashtable；D 反了，intset 二分查找 O(log N)，hashtable 平均 O(1)。 | | Q5 | C | 数据量大后 ZSet 从 ziplist/quicklist 切换到 skiplist + hashtable 双结构。skiplist 保证有序性（O(log N) 查找），hashtable 保证 O(1) 的 member 查找。D 不对，小数据量时用 quicklist/ziplist 省内存。 | | Q6 | B | Redis 7.0 的 native 优化中，小字符串用 SDS_TYPE_5 直接内嵌在 dictEntry 中，无需额外 malloc 分配独立对象。这减少了内存碎片并降低了 malloc 系统调用次数。 | ### 填空题答案 | 题号 | 答案 | 解析 | |------|------|------| | F1 | hashtable | ZSet 同时维护了一个 skiplist（按 score 升序排列）和一个 hashtable（按 member 做 O(1) 查找），两者同步更新，兼顾有序性和快速定位。 | | F2 | 8 | list-max-ziplist-size = -1 表示不限制（仅受 memory 约束），-2 <= 8KB，-3 <= 4KB，-4 <= 2KB，-5 <= 1KB（默认）。负数表示以 KB 为单位的大小上限。 | | F3 | 64 | 这是 Hash 编码切换的关键阈值之一：value 长度 > 64 字节 或元素数 > 512，都会促使 Redis 从 ziplist/zipmap 切换到 hashtable。 | ### 简答题参考答案 S1：**参考答案要点**： 1. 点赞总数使用 String 类型，通过 INCR 命令原子递增，简单高效；也可嵌套在 Hash 中用 field 存储多种计数。 2. 点赞帖子列表可用 ZSet，score 存点赞时间戳，member 存 post_id，天然有序且支持范围查询（ZREVRANGEBYSCORE）。 3. 帖子的点赞用户列表同样用 ZSet，score 为点赞时间，member 为用户 ID，配合 ZRANGE 取 Top-N。 4. 替代分析：List 虽然能存列表，但不支持按时间排序的高效插入；Hash 适合字段-值映射但不适合有序列表场景。 **评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点，并给出合理的替代方案分析。 ## 关联笔记 - [[03.Redis/core/RDB 与 AOF 持久化]] - [[03.Redis/core/集群与哨兵机制]] - [[03.Redis/strategies/多级缓存架构设计]] - [[03.Redis/strategies/缓存穿透击穿雪崩解决方案]]