Redis 底层数据结构
Redis 底层数据结构
Redis 的高性能并非来自单一结构，而是通过多种针对场景高度定制的数据结构实现。上层五种数据类型（String / List / Hash / Set / ZSet）只是抽象接口，真正的性能边界由底层结构决定。
SDS（Simple Dynamic String）
基本原理
SDS 是 Redis 自定义的字符串实现，替代 C 原生 char*。其核心是显式维护字符串长度与剩余空间。
典型结构：
1 | struct sdshdr { |
核心特点
- O(1) 获取长度（避免
strlen） - 支持二进制数据（不依赖
\0作为字符串的结尾） - 预分配与惰性释放，减少内存重分配
- 避免缓冲区溢出
使用到的数据类型
- String
- 所有 key
- Hash / List / Set / ZSet 内部元素
时间复杂度
- 获取长度：O(1)
- 追加：均摊 O(1)
- 修改：O(n)
链表（Linked List）
基本原理
双向链表，每个节点独立分配内存，保存前后指针与值指针。
核心特点
- 双向
- 无环
- 表头表尾指针
- 节点值为
void*，类型无关
使用到的数据类型
- List（早期实现）
- 发布订阅消息队列
- 慢查询日志
- 客户端列表
时间复杂度
- 头尾插入 / 删除：O(1)
- 按值查找：O(n)
现状
已被 quicklist 取代作为 List 的主要实现。
压缩列表（ziplist）
基本原理
一段连续内存，通过偏移量描述节点，无指针。
每个 entry 包含：
- 前一个 entry 的长度
- 当前数据编码与长度
- 实际数据
核心特点
- 极致节省内存
- 顺序存储，CPU cache 友好
- 插入可能引发连锁更新
使用到的数据类型
- List（旧）
- Hash（小规模）
- ZSet（小规模）
时间复杂度
- 访问：O(n)
- 插入 / 删除：O(n)
现状
Redis 7 之前使用，已被 listpack 全面替代。
哈希表（Dict）
基本原理
标准 Hash Table + 链地址法，支持渐进式 rehash。
核心结构：
- 两张哈希表（ht[0], ht[1]）
- rehash index
核心特点
- 扩容期间分批迁移
- 避免阻塞
- 支持自定义 hash 函数
使用到的数据类型
- Hash（大规模）
- Set
- ZSet（score 映射）
- 全局 key 空间
时间复杂度
- 查找 / 插入 / 删除：O(1) 平均，O(n) 最坏
- rehash：均摊 O(1)
整数集合（intset）
基本原理
用于存储仅包含整数的集合，底层为有序数组。
支持三种编码：
- int16_t
- int32_t
- int64_t（自动升级，不降级）
核心特点
- 内存占用极小
- 自动升级保证正确性
- 有序存储，二分查找
使用到的数据类型
- Set（所有元素为整数且数量较少）
时间复杂度
- 查找：O(log n)
- 插入 / 删除：O(n)
跳表（SkipList）
基本原理
多层链表结构，通过随机层级实现近似平衡。
核心特点
- 实现简单
- 范围查询高效
- 与哈希表组合使用
使用到的数据类型
- ZSet（按 score 排序）
ZSet 实际结构：
- Hash：member → score
- SkipList：按 score 排序
时间复杂度
- 查找 / 插入 / 删除：O(log n)
- 范围查询：O(log n + m)
quicklist
基本原理
链表 + ziplist/listpack 的混合结构。
- 外层：双向链表
- 内层：压缩列表（旧）或 listpack（新）
核心特点
- 降低指针开销
- 控制单块内存大小
- 平衡插入性能与内存效率
使用到的数据类型
- List（Redis 3.2+）
时间复杂度
- 头尾操作：O(1)
- 中间访问：O(n)
listpack
基本原理
ziplist 的重写版本，彻底解决连锁更新问题。
核心改进：
- 不再存储前一个 entry 的长度
- 更紧凑的编码设计
- 更明确的边界信息
核心特点
- 更安全
- 更易扩展
- 更适合大规模元素
使用到的数据类型
- List
- Hash
- ZSet
时间复杂度
- 访问 / 插入 / 删除：O(n)
- 实际性能优于 ziplist
总结
Redis 的设计逻辑明确：
- 小数据量 → 连续内存 → 节省内存
- 大数据量 → 复合结构 → 保证性能
- 写放大可接受，读路径必须稳定
理解这些底层结构，才能在以下问题上做出正确判断：
- key 设计
- value 结构选择
- 内存占用评估
- 性能瓶颈定位
Redis 的性能不是魔法，而是工程取舍的结果。
相关推荐
2025-12-12
RedisTemplate & StringRedisTemplate 使用指南
RedisTemplate & StringRedisTemplate 使用指南 前言 由于对于 Redis 始终停留在理论阶段——懂数据结构类型、数据结构底层实现、缓存击穿、缓存穿透、缓存雪崩，还有各种防xxx的方案，但是貌似都停留在学习上、代码阅读上，现在重新补充一下代码实现的细节上。 项目中很多地方使用了 StringRedisTemplate，其实是继承自 RedisTemplate 的。 然后就去搜 RedisTemplate 的 API、搜如何使用，挑选了7-8篇博客结合 ai 整理知识点如下： 从导入依赖开始 为什么是从导入依赖开始呢？主要是这个过程引发了我的疑问： 看到有一篇博客使用如下pom依赖： 12345<!--Redis--><dependency> <groupId>org.springframework.boot</groupId> ...
2025-12-13
Redis中Lua脚本的使用
Redis中Lua脚本的使用 参考资料：cnblogs.com、Redis Lua 脚本介绍 Redis 从 2.6 版本开始内置 Lua 脚本执行引擎，用于在服务器端组合多个 Redis 命令为一个原子操作，从而避免客户端多次往返网络、保证复杂逻辑的原子性执行。Lua 是一种轻量级、可嵌入的脚本语言，非常适合嵌入 Redis 这种高性能内存数据库中。 Lua 在 Redis 中执行时无需额外配置，只需通过命令将脚本发送到 Redis。脚本由 Redis Server 内的 Lua 5.1 解释器运行。Redis 脚本将命令组合在一起，避免多次网络往返，并在执行期间阻塞其他客户端命令，确保原子性。脚本执行结果可返回值给客户端。 Lua 脚本基本语法 Lua 语法简单，适合嵌入式脚本应用。基本数据类型包括：nil（空）、boolean（布尔值）、number（数字）、string（字符串）和 table（表）。table 是 Lua 的核心数据结构，它既可表现为数组也可表现为字典。 变量声明： 12name = 'example' --...
2025-11-28
Redis 数据类型
Redis 数据类型 所有的数据类型有：String、Hash、List、Set、Zset、BitMap、HyperLogLog、GEO、Stream String 介绍 String 就是最基本的 Key-Value 类型数据，key 是唯一标识，Value 可以是字符串也可以是数字（整数、浮点数）。 底层是由 SDS（Simple Dynamic String）进行实现。 常用指令 指令 描述 SET key value 设置指定 key 的值。如果 key 已经存在，则覆盖旧值。 GET key 获取指定 key 的值。如果 key 不存在，返回 nil。 GETRANGE key start end 获取指定 key 中字符串值的子字符串。 SETEX key seconds value 设置 key 的值，并同时设置过期时间（以秒为单位）。 PSETEX key milliseconds value 设置 key 的值，并同时设置过期时间（以毫秒为单位）。 SETNX key value 仅在 key 不存在时设置 key 的值。如果...
2025-12-22
Redis 使用实践
这一部分更多偏实践部分，理论部分见其余 Redis 相关博客
2025-12-22
Redis 线程模型
Redis 线程模型Redis 常被描述为“单线程高性能”的代表，但单线程并不等于简单或低效。准确理解 Redis 的线程模型，需要区分：命令执行、网络 I/O、后台任务这三条路径。 Redis 的单线程指的是什么是指—— Redis 的命令执行路径（command execution）是单线程的。 具体来说： 所有客户端命令，统一在 主线程 中，按顺序完成：读取 → 解析 → 执行 → 返回结果 这意味着： 不需要加锁、命令天然具备原子性、数据结构实现可以极度简化 但是，Redis 并不是整个进程只有一个线程 基于内存的设计Redis 将所有核心数据结构存放在内存中，而不是磁盘。 这带来的不仅是“快”这么简单： 避免磁盘 I/O 阻塞 单次命令执行时间高度可控 延迟分布稳定，适合单线程顺序执行模型 相比之下，频繁访问磁盘的系统（如传统关系型数据库）更容易出现阻塞点，不适合纯单线程执行所有逻辑。 关于数据不丢失的问题Redis...
2025-12-22
Redis 过期删除策略+缓存淘汰策略
Redis 过期删除策略在介绍 Redis 的过期删除机制之前，需要先说明：定时删除、惰性删除、定期删除是对过期数据清理思路的抽象划分，用于分析不同策略在 CPU 开销与内存占用之间的取舍。实际的高性能缓存系统通常不会采用其中某一种，而是进行组合设计。 常见的过期删除策略1. 定时删除定时删除指的是：当键到达过期时间的瞬间立即删除该键。 其实现通常需要： 为每一个设置了过期时间的 key 维护独立的定时事件（如定时器或最小堆） 到期后触发删除回调 优点： 过期键能够被及时清理 内存利用率高 缺点： 定时事件数量与过期 key 数量近似线性相关 当过期 key 较多时，定时回调会占用大量 CPU 严重影响主线程吞吐量 因此，Redis 并未采用这种高精度但高成本的策略。 2. 惰性删除惰性删除的核心思想是：不主动删除过期 key，仅在访问时检查其是否过期。 执行流程： 客户端访问 key Redis 判断 key 是否已过期 若已过期，立即删除并返回 key 不存在 优点： 对 CPU 非常友好 不做无意义的主动扫描 缺点： 如果某些 key...
