2. Redis 核心数据结构回顾：String、Hash、List、Set、Sorted Set 的底层编码与适用场景

Redis 之所以能成为企业级缓存与中间件的首选，不仅因为其纯内存操作，更在于其丰富的数据结构以及针对不同场景自动切换的底层编码机制。理解这五种核心数据结构的底层实现与适用场景，是进行热点削峰与慢查询调优的基础。

2.1 数据结构总览与编码策略

Redis 为每种数据类型提供了多种底层编码（encoding），并在运行时根据数据规模、元素类型自动切换，以在内存占用与操作效率之间取得最佳平衡。下表总结了五种数据结构的默认编码与切换条件：

2.2 String：最基础的原子操作单元

String 是 Redis 最基础的数据类型，最大支持 512MB。其底层编码分为三种：

• int：存储整数时使用，支持 INCR/DECR 原子操作，是计数器、限流器的基础。
• embstr：存储 ≤44 字节的短字符串，内存连续分配，读写性能最优。
• raw：存储长字符串，内存分两次分配，适合大文本或序列化对象。

典型场景：

• 热点数据缓存（用户 Session、配置项）
• 分布式锁（SETNX + 过期时间）
• 计数器（PV/UV、限流令牌）
• 位图统计（活跃用户、签到）

2.3 Hash：对象级缓存的利器

Hash 适合存储结构化对象（如用户信息、商品详情），支持对单个字段进行读写，避免序列化整个对象的开销。

底层编码对比：

• listpack（紧凑编码）：字段数少且值小时使用，内存占用极低，读写复杂度 O(n) 但 n 很小。
• hashtable（字典编码）：字段数多或值大时自动升级，读写复杂度 O(1)，但内存开销更大。

2.4 List：消息队列与时间轴

List 底层使用 quicklist 结构，它是一个由多个 ziplist 节点组成的双向链表。每个 ziplist 节点可以存储多个元素，在内存紧凑性与操作效率之间取得平衡。

适用场景：

• 轻量级消息队列（LPUSH + BRPOP）
• 时间轴数据（最新动态、操作日志）
• 数据流缓冲（批量写入后消费）

2.5 Set：去重与集合运算

Set 底层使用 intset（整数集合）或 hashtable（字典）。intset 采用有序数组存储，支持二分查找；当元素类型不统一或数量超限时，自动升级为 hashtable。

典型应用：

• 标签系统（用户兴趣标签、文章分类）
• 去重过滤（已读消息、已领取优惠券）
• 集合运算（共同好友、推荐交集）

Set 的 SINTER（交集）、SUNION（并集）、SDIFF（差集）操作在大集合上可能成为 CPU 密集型慢查询，建议在业务低峰期执行或使用 SINTERSTORE 缓存结果。

2.6 Sorted Set：排行榜与优先级队列

Sorted Set 是 Redis 最复杂也最强大的数据结构，底层结合了 skiplist（跳表） 与 dict（字典）：

• skiplist：维护元素的有序性，支持范围查询（ZRANGE、ZREVRANGE）和排名操作（ZRANK）。
• dict：提供 O(1) 的成员查找，确保分值更新的效率。

底层编码切换：

• listpack：元素数 ≤ 128 且分值长度 ≤ 64 字节时使用，内存紧凑。
• skiplist + dict：数据量增大后自动升级，支持高效的范围查询与随机访问。

核心场景：

• 实时排行榜（游戏积分、热榜排序）
• 延迟队列（时间戳作为分值，ZRANGEBYSCORE 获取到期任务）
• 滑动窗口限流（时间戳作为分值，ZREMRANGEBYSCORE 清理过期数据）

2.7 数据结构选型决策矩阵

在实际业务中，选择合适的数据结构直接影响系统性能与维护成本。下表总结了不同场景下的推荐选型：

2.8 慢查询与编码关联分析

理解底层编码有助于定位慢查询根因。以下是一些常见问题模式：

• Hash 大字段：当 Hash 字段数超过 5000 时，hgetall 可能耗时 > 10ms，建议拆分为多个小 Hash 或使用 hmget。
• List 长尾访问：对长度超过 10 万的 List 执行 LINDEX 或 LSET，时间复杂度 O(n)，应改用 Sorted Set 或维护索引。
• Set 大集合运算：SINTER 对两个 10 万级 Set 求交集可能耗时 50ms+，建议使用 SINTERSTORE 缓存结果或改用 Bloom Filter。
• Sorted Set 分值更新：频繁 ZADD 更新同一元素的分值会导致 skiplist 节点删除重建，建议使用 ZINCRBY 原子更新。