Redis五种数据类型底层

String

• 底层数据结构是SDS（简单动态字符串）
• SDS可以保存文本数据以及二进制数据（C语言字符串不行）
• SDS有变量监测字符串长度，因此获取长度为O(1)
• SDS拼接字符串会自动扩容，且会检查空间要求，因此API安全不会造成缓冲区溢出

---

List

Redis 的 List 结构为了平衡内存利用率 和操作性能，其底层实现经历了几次重大的架构演进。

目前（Redis 7.0+），List 的核心底层结构是 quicklist ，而 quicklist 的每个节点内部使用的是 listpack。

1. 早期：ziplist + linkedlist

早期的 Redis 根据数据量大小，在两种结构之间切换：

• ziplist (压缩列表) ：当元素少且小时使用。它是一块连续内存，非常省内存，但由于是连续存储，修改时可能触发"连锁更新"（Cascade Update），性能不稳定。
• linkedlist (双向链表) ：当数据量大时切换。每个节点独立，虽然插入删除快，但内存碎片 严重，且每个节点都要存 prev 和 next 指针，额外空间开销巨大。

为了结合两者的优点，Redis 引入了 quicklist。

2. Redis7前：quicklist + ziplist

Redis7前quicklist 实际上是一个以 ziplist 为节点的双向链表。

• 宏观上 ：它是一个双向链表，所以两端的 LPUSH、RPUSH 等操作复杂度是 O(1)O(1)O(1)。
• 微观上：每个链表节点并不是只存一个元素，而是存一个包含多个元素的"压缩块"。

设计意图：

• 通过链表结构解决大块内存申请的困难。
• 通过压缩块（ziplist/listpack）减少指针开销，提高 CPU 缓存命中率。

3. Redis7后：quicklist + listpack

在 Redis 7.0 之后，quicklist 内部的压缩块由 ziplist 全面升级为 listpack。

为什么 ziplist 被抛弃了？

ziplist 有一个致命缺陷：连锁更新 (Cascade Update) 。

ziplist是压缩链表，顺序表但每个元素长度不固定，需要记录每个entry的长度

在 ziplist 中，每个 entry（ziplist中的一个元素） 都会记录上一个 entry 的长度。如果上一个 entry 的长度稍微增加，导致长度字段从 1 字节变成 5 字节，那么当前 entry 的总长度就会变，进而可能导致下一个 entry 也要变......这会导致 O(N2)O(N^2)O(N2) 的写性能崩溃。

listpack 是如何解决的？

listpack 同样是连续内存，但它不再记录"上一个元素的长度"，而是记录**"当前元素的长度"**。

• 读取时：通过当前元素的结尾标识，可以反向计算出当前元素的起始位置。
• 解耦：一个元素的长度变化，完全不会影响其他元素的长度字段，从物理上彻底消除了连锁更新。

4. 关键参数配置

你可以通过配置来微调 List 的存储密度，从而在内存和 CPU 之间寻找平衡点：

• list-max-listpack-size：控制每个 quicklist 节点（即 listpack）的大小。

  • 配置为负数（如 -2）表示限制字节数（如 8KB）。
  • 配置为正数表示限制元素个数。

• list-compress-depth：压缩深度。

  • 如果 List 非常长，中间的数据很少访问，Redis 可以对 quicklist 中间的节点进行 LZF 算法压缩，进一步节省空间，只保留两端节点不压缩。

---

Hash

目前（Redis 7.0+），Hash 的底层主要由 listpack 和 hashtable (dict) 组成。

1. 结构一：listpack

当你的 Hash 中字段（Field）较少，且每个字段的 Value 都不大时，Redis 会使用 listpack。

• 物理形式 ：一整块连续的内存空间。

• 存储逻辑 ：每一个 Hash 的键值对在 listpack 中表现为相邻的两个 Entry（前一个是 Field，后一个是 Value）。

• 优势：

• 极致省内存：由于内存连续且没有多余的指针开销，它比传统的哈希表要省得多。

• 缓存友好：数据紧凑，CPU 预取效率高。

• 缺陷 ：查询复杂度是 O(N)O(N)O(N)。因为是连续内存，寻找特定 Field 需要从头开始遍历扫描。

2. 结构二：hashtable (dict)

一旦 Hash 的规模超过了预设阈值，它就会"进化"为 hashtable （在源码中称为 dict）。

• 物理形式：由数组（Buckets）+ 链表（解决哈希冲突）组成。
• 存储逻辑 ：通过哈希函数计算 Hash(Field)(modSize)Hash(Field) \pmod{Size}Hash(Field)(modSize)，将数据映射到对应的桶位。
• 优势 ：真正的 O(1)O(1)O(1) 查找性能。无论你有 100 个还是 100 万个字段，定位速度几乎一样。
• 核心特性：渐进式 rehash
  为了避免在扩容时一次性搬运海量数据导致 Redis "假死"，dict 内部会维护两个哈希表 （ht[0] 和 ht[1]）。
• 数据迁移不是瞬间完成的。
• 每执行一次增删改查，Redis 就顺手搬运几个桶的数据到新表。
• 直到 ht[0] 搬空，再彻底切换到 ht[1]。

3. 转换的"分水岭"

Redis 默认通过两个配置参数来控制什么时候从 listpack 切换到 hashtable：

1. 数量阈值 ：hash-max-listpack-entries（默认 512 个）。
2. 大小阈值 ：hash-max-listpack-value（任一字段或值的字节数超过 64）。

注意 ：这种转换是单向的 。一旦从 listpack 升级为 hashtable，即便你删除了大量数据，它通常也不会自动退化回 listpack（除非通过 reconstruct 或重启加载 RDB）。

---

Set

目前（尤其是 Redis 7.2 版本之后），Set 的底层实现由三种结构支撑：intset 、listpack 和 hashtable (dict)。

1. 结构一：intset（整数集合）------极致的内存压缩

当你往 Set 里丢的数据全是整数 ，且数量不多时，Redis 会动用 intset。

• 物理形式 ：一块连续的内存 ，内部是一个有序的数组。

• 核心特性：自动升级（Promotion）：

• 它会根据存入整数的大小，自动选择 int16_t、int32_t 或 int64_t 来存储。

• 如果你存的是小数字，它就用 2 字节存；一旦混入一个大的，它会瞬间把整个数组"升级"到 4 或 8 字节。注意：不支持降级。

• 性能 ：查找采用二分查找 ，复杂度为 O(log⁡N)O(\log N)O(logN)。因为内存连续，即使是 O(log⁡N)O(\log N)O(logN) 在小规模下也飞快。

2. 结构二：listpack（Redis 7.2 引入的新宠）

在 Redis 7.2 之前，只要 Set 里出现一个字符串，或者整数多了，就会直接跳到哈希表。现在的版本更细腻了：如果数据量还不够大，它会先用 listpack 顶一阵子。

• 设计初衷：替换掉在这种"尴尬规模"下过于臃肿的哈希表。
• 存储逻辑：和 List/Hash 里的 listpack 一样，连续内存存储。
• 触发条件 ：当元素包含字符串，或者整数数量超过 intset 限制，但还没达到 hashtable 阈值时使用。

3. 结构三：hashtable (dict)

当集合变得很大（默认超过 512 个元素）时，Set 会演化为 hashtable。

• 物理形式：标准的哈希表。
• 巧妙之处 ：Set 的哈希表其实就是把 Hash 类型的 Value 置为 NULL。
• 性能 ：真正的 O(1)O(1)O(1) 查找。无论集合里有一万个还是十万个元素，判断 SISMEMBER 的速度都是恒定的。

---

ZSet

Redis 的 ZSet （有序集合）是 Redis 中最复杂、也最精妙的数据结构。它既要支持根据成员（Member）查找分数（Score） ，又要支持按照分数范围进行快速检索。

1. 结构一：listpack

当 ZSet 的元素数量较少，且每个元素的体积较小时，Redis 使用 listpack。

• 物理形式：一整块连续内存。
• 排列逻辑 ：元素和分数交替出现，且按分数从小到大紧凑排列 。
  [member1, score1, member2, score2, ...]
• 性能 ：查找和插入的复杂度为 O(N)O(N)O(N)。但在数据量极小时（默认 128 个以内），其 CPU 缓存命中率极高，实际表现非常出色。

2. 结构二：Skiplist + Dict

当 ZSet 变大时，它会同时启用两个数据结构：跳表（Skiplist） 和 哈希表（Dict）。

A. 跳表 (Skiplist)：负责"有序"

跳表是 ZSet 的灵魂。你可以把它看作是一个支持二分查找的有序链表。

• 实现原理：在普通有序链表的基础上，建立多层"索引"。
• 查找过程：先在高层"大步跳"，迅速锁定范围，再在底层"小步走"。
• 性能 ：平均查找、插入、删除复杂度均为 O(log⁡N)O(\log N)O(logN)。
• 为什么不用平衡树（红黑树）？
• 实现更简单：跳表代码量更少。
• 范围查询更强：跳表底层是链表，找到起点后直接向后遍历即可；平衡树做范围查询需要复杂的跨分支搜索。

B. 哈希表 (Dict)：负责"查询"

虽然跳表很快，但如果你只想知道 user:100 的分数是多少（ZSCORE 命令），在跳表里找依然需要 O(log⁡N)O(\log N)O(logN)。

• 实现原理 ：维护一个 member -> score 的映射。
• 性能 ：O(1)O(1)O(1) 即可拿到分数。

协作模式 ：两者共同指向同一份成员和分数的内存对象。Dict 负责 O(1)O(1)O(1) 查分，Skiplist 负责 O(log⁡N)O(\log N)O(logN) 范围检索。

---