全网最全Redis底层实现数据结构详解

原创 于 2025-12-23 14:15:00 发布 · 251 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据结构 #redis底层数据结构

Redis 常用数据类型的底层实现数据结构（详细版）

面向：Redis 5/6/7 使用者（Redis 7 仍是主流）。
你关心的点：同一种逻辑类型在不同规模下会切换不同 encoding（底层结构），这会直接影响内存、性能、AOF/RDB、复制成本。
说明：Redis 内部实现会随版本演进（阈值/编码名可能变），下面以 Redis 6/7 的通用规律为主，关键地方会注明“不同版本可能略有差异”。

目录

1. 两个概念：逻辑类型 vs encoding

  • 逻辑类型（data type）：你在命令层面看到的：String/Hash/List/Set/ZSet/Stream…
  • encoding（内部编码）：Redis 在内存里真实使用的结构。
    例如 Hash 可能是 listpack 或 hashtable，ZSet 可能是 listpack 或 skiplist。

你可以用：

TYPE key
OBJECT ENCODING key

来分别看到逻辑类型与内部编码。

2. Redis 里最常见的底层结构总览

下面这些是你理解 Redis 内部的“乐高积木”：

2.1 SDS（Simple Dynamic String）

  • Redis 自己的字符串结构（不是 C 的 char*）。
  • 特点：
    • O(1) 获取长度（len 字段）
    • 支持二进制安全（可存 \0）
    • 有预分配策略减少频繁 realloc

2.2 dict（哈希表）

  • Redis 的核心结构：很多类型最终都会落到 dict。
  • 用途：Key 空间本身（数据库字典）、Hash、Set、ZSet 的 member->score 映射等。
  • 特点：
    • 渐进式 rehash（避免一次性扩容卡顿）
    • 平均 O(1) 查找/插入/删除

2.3 listpack（紧凑列表）

  • Redis 取代 ziplist 的“新一代紧凑编码”（ziplist 在新版本逐步淘汰/移除）。
  • 用途：小 Hash、小 ZSet、Stream 的 entries 等。
  • 特点：
    • 连续内存，极省空间（适合小规模）
    • 插入/删除可能涉及内存移动：大了就不划算，所以需要阈值切换到更适合的结构

2.4 quicklist（快速列表）

  • List 的主要实现方式（把“链表 + 压缩块”结合）。
  • 本质：双向链表，每个节点挂一个 listpack（或历史上的 ziplist）。
  • 目的：既能两端 O(1) push/pop，又能比纯链表省内存。

2.5 intset（整数集合）

  • Set 在“全是整数且数量小”时的省内存编码。
  • 特点：
    • 内部是有序整数数组（按 int16/int32/int64 自适应升级）
    • 查找用二分（O(log n)），插入可能移动（O(n)）
    • 一旦出现非整数元素就会升级成 hashtable

2.6 skiplist（跳表）

  • ZSet 在大规模时用于按 score 排序。
  • 特点：
    • 范围查询、按 rank 查询效率高（O(log n + m)）
    • 与 dict 配合：dict 负责 member->score O(1)，skiplist 负责有序视图

2.7 radix tree（基数树）

  • Stream 的核心索引结构（按消息 ID 有序组织）。
  • 特点：
    • 适合存储大量相似前缀的 key（Stream 的 ID 很符合这种模式）
    • 支持范围迭代

3. String 的底层实现

String 在 Redis 内部有几种常见编码：

3.1 int（整数编码）

  • 当 value 是可解析的整数并且范围合适时，Redis 会用整数直接存。
  • 你会看到 OBJECT ENCODING key 返回 int。
  • 好处：省内存 + INCR/DECR 快（避免字符串到整数转换的额外成本）

3.2 embstr（短字符串优化）

  • 小字符串会用 embstr：redisObject 头 + SDS 一次性分配在同一块内存里（减少一次 malloc）。
  • 好处：小对象非常常见，embstr 能明显降低碎片和分配开销。

3.3 raw（普通 SDS）

  • 字符串较大时，用 raw（常规 SDS + 对象头分配）。
  • 特点：更通用，但分配次数更多。

小结：String 的编码选择本质是“减少分配 + 减少额外数据结构”。

4. List 的底层实现（quicklist）

4.1 结构长啥样

  • List 使用 quicklist：
    • 外层：双向链表节点
    • 每个节点：一个 listpack（紧凑存若干元素）
    • 节点的 listpack 可以做 LZF 压缩（取决于配置与数据分布）

4.2 为什么不用纯链表 / 纯数组？

  • 纯链表：每个元素一个节点，指针开销巨大，CPU cache 也差。
  • 纯数组（连续内存）：两端 push/pop 不方便（需要搬移）。
  • quicklist：折中方案：
    • 两端操作仍然快
    • 通过“块”减少指针数量
    • 通过压缩减少内存

4.3 性能直觉

  • LPUSH/RPOP：通常 O(1)（落在头尾块）
  • LRANGE：需要遍历块并定位，返回越多成本越高
  • 坑：单个 List 超大 -> quicklist 节点很多 -> 遍历、复制、RDB/AOF 都变重

5. Hash 的底层实现（listpack/hashtable）

Hash 常见两种编码：

5.1 listpack（小 Hash）

  • 当 field 数量小、field/value 长度都比较小，Redis 会用 listpack。
  • 结构：一个紧凑块按顺序存 field1 value1 field2 value2 ...
  • 优点：极省内存
  • 缺点：
    • 查找需要线性扫描（O(n)），但 n 很小的时候反而比 hashtable 更快（cache 友好）
    • 插入/删除可能触发内存移动

5.2 hashtable（大 Hash）

  • 当 Hash 变大或出现“大 field/value”，会升级为 hashtable（dict）。
  • 优点：查找/更新平均 O(1)
  • 缺点：指针/哈希桶开销更高，内存更大

经验：Hash 适合“对象字段”模型，但如果单个 Hash 的 field 上万级，HGETALL 就会非常危险（网络+复制+慢查询）。

6. Set 的底层实现（intset/hashtable）

6.1 intset（小且全整数）

  • 适用：成员全部是整数，并且数量较小。
  • 结构：有序整数数组（紧凑）
  • 查找：二分 O(log n)
  • 插入：O(n)（可能移动）
  • 升级：
    • intset 会在需要更大整数范围时升级底层存储宽度（16->32->64）
    • 一旦加入非整数成员，整体升级为 hashtable（不可逆）

6.2 hashtable（通用 Set）

  • 结构：dict，key=member，value=NULL
  • 平均 O(1) 增删查
  • 内存：比 intset 大，但更通用、适合大集合

经验：Set 用来“去重 + membership”，很强。但 SMEMBERS 对大 Set 会直接把你拖死（一次性返回太多）。

7. ZSet 的底层实现（listpack/skiplist+dict）

ZSet 同时需要：

  1. member -> score（快速查）
  2. 按 score 排序（范围查、排行）

所以它的内部通常是“两套结构并存”。

7.1 listpack（小 ZSet）

  • 小规模时用 listpack 存：
    • member1 score1 member2 score2 ...
  • 优点：省内存，cache 友好
  • 缺点：查找/更新需要扫描（O(n)），但 n 小时没问题

7.2 skiplist（大 ZSet）

当 ZSet 变大后会升级成组合结构：

  • dict：member -> score（O(1)）
  • skiplist：按 (score, member) 排序（O(log n) 范围查）

范围查询复杂度通常：O(log n + m)（m 为返回个数）。

经验：排行榜、延时队列大多靠 ZSet。真正的坑不是 ZSet 慢，而是你一次 ZRANGE 拿 10 万条 + 带 score + 网络/序列化/复制一起炸。

8. Bitmap 的底层实现（本质是 String）

Bitmap 不是独立结构，本质就是 String：

  • SETBIT key offset 1 会把 String 当 bit 数组用
  • 内部还是 SDS（raw/embstr 等），只是读写时按 bit 位操作

坑点非常经典：

  • offset 很大（比如 1e9）会导致 String 直接扩容到巨大长度（稀疏空间不友好）
    -> 一瞬间内存爆炸。

9. HyperLogLog 的底层实现（稀疏/稠密 + String）

HyperLogLog（HLL）在 Redis 内部也存成 String（字节数组），但有两种表示：

  • Sparse（稀疏）：元素较少时更省空间
  • Dense（稠密）：元素较多时固定大小更高效

你用 PFADD/PFCOUNT 时，Redis 会在稀疏与稠密之间自动转换。

关键点：

  • HLL 能把海量去重计数压到很小的内存（但有误差）
  • 只适合“要数量，不要明细成员”

10. GEO 的底层实现（ZSet）

GEO 在 Redis 内部是 ZSet：

  • member 是地点标识（比如店铺 ID）
  • score 存储经过编码的地理坐标（geohash 相关的编码映射）

所以你看到：

  • TYPE geoKey 是 zset
  • OBJECT ENCODING geoKey 也会是 zset 的编码（listpack/skiplist）

11. Stream 的底层实现（radix tree + listpack）

Stream 是 Redis 最“像 MQ”的结构，它的内部相对复杂：

11.1 顶层索引：radix tree

  • 以消息 ID（如 1690000000000-0）为 key，做有序组织与范围扫描

11.2 消息体：listpack

  • 每条消息的 fields/value 通常用紧凑结构存（listpack）
  • 还会做一些“共享字段名”的优化（很多消息字段相同，能省不少）

11.3 消费者组（Consumer Group）相关结构

  • PEL（Pending Entries List）等也有专门结构维护（内部仍会大量用 dict/listpack/radix tree 组合）

经验与坑：

  • Stream 会不断增长，不裁剪就会越来越大
    • XTRIM ... MAXLEN ~ N 是必备动作
  • pending 不处理会堆积（消费者挂了、没 ack）

12. 编码切换阈值：你应该怎么理解

Redis 选择 encoding 的核心目标只有两个：

  1. 小规模：省内存 + cache 友好（listpack/intset/embstr）
  2. 大规模：保证操作复杂度（hashtable/skiplist）

切换触发因素一般是：

  • 元素数量超过某个阈值（比如 Hash/ZSet 的最大小编码元素数）
  • 单个元素长度超过阈值（field/value/member 太长）
  • 数据类型限制被打破（Set 加入非整数，intset -> hashtable）

阈值通常来自配置项（不同版本命名略有区别），典型的你会见到：

  • Hash/ZSet 的“max listpack entries / max listpack value”
  • List 的 quicklist 块大小、压缩策略等

你不需要死背阈值数字：记住“小而密用紧凑结构，变大或变长就升级”就够了。
真要确认阈值：看你线上 Redis 的配置与版本，再用 OBJECT ENCODING 实测。

13. 如何在线上确认 encoding 与内存占用

13.1 看类型与编码

TYPE mykey
OBJECT ENCODING mykey

13.2 看这个 key 大概吃了多少内存

MEMORY USAGE mykey

13.3 看总体内存与碎片

INFO memory
MEMORY STATS
MEMORY DOCTOR

13.4 找慢命令（经常是“大结构被全量读/写”）

SLOWLOG GET 20
INFO commandstats

14. 典型性能/内存坑：从底层结构角度解释

14.1 HGETALL / SMEMBERS / 大范围 ZRANGE

  • 问题本质：你把一个“大结构”全量拉出来
  • 代价：
    • Redis 单线程要遍历
    • 返回数据巨大占用网络
    • 主从复制也会更重
  • 建议：
    • Hash：按字段读（HMGET），或拆分 key
    • Set：避免 SMEMBERS；用 SCAN/SSCAN 分批
    • ZSet：范围 + LIMIT 分页

14.2 大 Key

  • List 超长：quicklist 节点多，遍历与持久化成本高
  • Hash 超大：hashtable 很大，rehash/复制/备份成本高
  • Bitmap offset 极大：String 直接膨胀
  • Stream 不裁剪：radix tree + entries 越来越大

解决思路：

  • 拆分（分片 key）
  • 限制（写入前做 guard）
  • 分批访问（SCAN/SSCAN/HSCAN/ZSCAN）
  • TTL + 随机抖动（避免同时过期）

14.3 热点 key（Hot Key）

  • 即使编码很省内存，也会被访问频率打爆单核
  • 常见：热点计数器、热点排行榜、热点配置
  • 解决：
    • 本地缓存/多级缓存
    • 拆分计数（分桶再汇总）
    • 业务层限流/降级

最后给你一个“选型+底层直觉”的一句话

  • 小对象/小集合：Redis 会用 紧凑编码（embstr/listpack/intset） 把内存压到极致
  • 规模上来：Redis 会切换到 dict/skiplist/quicklist/radix tree 保证复杂度与可用性
  • 真正线上事故往往不是“某结构慢”，而是你对“大结构做了全量操作”。
CodeAmaz
关注
深入学习 Redis - 主从结构配置、流程、底层原理（全网最详细）
CYK_byte的博客
08-11 9769
单点问题可用性：如果这个机器挂了，意味着服务就中断了.性能：支持的并发量也是比较有限的.因此引入分布式系统，主要也是为了解决上述的单点问题~ 分布式系统中，往往需要多个服务器来部署 redis 服务，从而构成redis 集群，此时就可以让这个集群给整个分布式系统中的其他服务，提供更稳定 / 更高效的数据存储功能.本章主要来讲一下 redis 部署方式中的主从模式~
Spring Boot进阶(63)：「超详细」利用 Redis 实现高效延时队列：踩坑、优化、实践
**My Coding Family**
08-31 3942
这篇文章分享了作者在使用 Redis 实现延时队列的过程中所遇到的坑和优化经验。作者首先介绍了 Redis 的有序集合数据结构，以及如何利用有序集合作为延时队列的底层实现。接着，作者分享了在实践中遇到的一些问题，例如服务宕机重启后需要重新拉取超时任务，任务过多导致 Redis 内存占用过高等。最后，作者给出了对延时队列的优化建议，例如采用批量删除任务和使用多个 Redis 实例来分散负载等。整篇文章结合了理论和实践，对于想要使用 Redis 实现高效延时队列的开发者来说是一份很有价值的参考资料。
全网最全Redis面试题
Alex
04-15 2402
Redis常见面试题整合,供大家参考。 题目来源 https://blog.youkuaiyun.com/Design407/article/d...
Redis内部数据结构详解(3)——robj
smart_an的专栏
02-24 605
void *ptr;} robj;type: 对象的数据类型。占4个bit。可能的取值有5种：OBJ_STRING, OBJ_LIST, OBJ_SET, OBJ_ZSET, OBJ_HASH，分别对应Redis对外暴露的5种数据结构（即我们在第一篇文章中提到的第一个层面的5种数据结构）。encoding: 对象的内部表示方式（也可以称为编码）。占4个bit。可能的取值有10种，即前面代码中的10个OBJ_ENCODING_XXX常量。lru: 做LRU替换算法用，占24个bit。
全网最详细Redis高阶从入门到精通
Java技术大联盟
04-26 1250
全网最详细Redis从入门到入坑 1.Redis 基础数据结构 Redis 有 5 种基础数据结构，分别为：  ● string (字符串)  ● list (列表)  ● set (集合)  ● hash (哈希)  ● zset (有序集合)。 string (字符串)  ● 字符串 string 是 Redis 最简单的数据结构。  ● Redis 所有的数据结构都是以唯一的 key 字符...
Redis第一讲 Redis数据结构之简单动态字符串（SDS）
程序员路同学
06-25 1394
Redis第一讲 Redis五种基本类型的底层数据结构 SDS 相比C 字符串的优势： 整个Redis主体数据结构图如下： List是一个有序(按加入的时序排序)的数据结构，Redis采用quicklist（双端链表） 和 ziplist 作为List的底层实现。可以通过设置每个ziplist的最大容量，quicklist的数据压缩范围，提升数据存取效率 Hash 数据结构底层实现为一个字
Redis数据类型详解
最新发布
zhiyuanIT的专栏
12-23 397
全网最强，最详细的Redis数据类型详解
Redis对象详解
weixin_45563088的博客
03-19 2582
文章目录五种基本数据类型Redis对象的组成字符串对象SDS不同编码的区别int编码embstr 和 rawRedis如何选择编码列表对象linkedlist编码ziplist编码压缩列表内存连续压缩列表的构成压缩列表节点的构成哈希对象ziplist编码hashtable编码字典Rehash集合对象有序集合对象ziplist实现skiplist实现为什么还要使用字典？skiplist小结 五种基本数据类型 Redis支持五种基本数据类型：String，Hash，List，Set，Zset / Sorted
Redis 详解
热门推荐
weixin_45683550的博客
01-19 3万+
Redis redis 简介 redis 采用的是单线程的 KV 模型，由 C 语言编写， 1. Redis 中的事务？ 2. Redis 中的数据结构 3. Redis 中如何保证缓存和数据库双写时的数据一致性？ 4. 如何使用 Redis 做异步队列和延时队列？ 5. Redis 中的过期策略 6. Redis 中的内存淘汰机制 7. Redis 中的缓存击穿，缓存穿透，缓存雪崩 8. Redis 中的分布式锁 9. Redis和memcache的区别 10. Redis 中的持久化机制 11. Red
20分钟搞定Redis基础，全网最新最全保姆级教程！！！
智潮先锋聚集地
05-08 2849
20分钟内搞定Redis基础，关注不迷路，随后更新Redis进阶知识，全网最全最新保姆级教程！
全网最全的redis深入解析
qq749812679的博客
04-17 705
插入过程：跳跃表插入节点的时候，首先需要通过score找到自己的位置，也就是需要先走一步查找过程，找到新节点所处的位置的时候就创建一个新节点，并对新节点分配一个层数（这里层数的分配redis采用的是random随机机制，分配层数从1开始，每次晋升为上一层的概率为0.25），层数分配完了之后将前后指针进行赋值将新节点与旧节点串起来，如果层数大于当前的level还需要进行level的更新操作。故障节点变为客观下线后，如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它，从而保证集群的高可用。
1.17---区块链如何实现“数据同步”？节点、P2P 网络机制
鄙人kunzhi96，感恩遇见！
07-15 1万+
【摘要】本文系统解析区块链数据同步机制。文章对比Web2中心化同步与Web3分布式同步的本质差异，揭示区块链通过P2P网络和共识协议实现节点间数据一致的原理。核心内容包括：数据同步对象（区块、交易、状态）、节点类型划分（全节点/轻节点/验证节点）、Gossip协议传播机制、完整同步与快照同步策略，以及开发者接入节点的工程实践。本文为Web2开发者提供了理解区块链底层架构的关键视角，涵盖从理论到实践的完整知识体系。
Redis Cluster中Gossip协议的实现机制解析
本文围绕“Redis Cluster Gossip协议详解”这一主题，深入剖析了Gossip协议在Redis集群中的具体实现方式、通信流程、状态管理以及源码层面的关键结构，为理解分布式系统的自组织与容错能力提供了极具价值的技术参考...
Redis 安全加固终极指南
SmallBull的博客
12-17 1142
Redis安全加固指南摘要： 本文提供Redis数据库全面安全防护方案，涵盖7个关键维度：1）网络隔离：通过IP绑定和防火墙限制访问；2）身份认证：推荐使用Redis6+的ACL精细化权限控制；3）命令安全：禁用或重命名FLUSHALL等高危命令；4）通信加密：配置TLS/SSL传输加密；5）运行安全：以非root用户运行并设置内存保护；6）监控审计：开启日志记录和审计功能；7）应急响应：制定入侵处理预案。强调安全核心原则是最小权限+多层防御，必须完成绑定IP、强密码认证、禁用高危命令等基础防护，并建议定期
Redis 的 RDB 持久化
m0_59021776的博客
12-22 641
RDB 持久化是 Redis 的基础持久化方式，核心是通过快照文件保存全量数据手动触发用BGSAVE，避免SAVE阻塞主进程；自动触发通过redis.conf的save参数配置，平衡性能和数据安全性；恢复时 Redis 自动加载 RDB 文件，AOF 开启时优先加载 AOF；生产环境建议 RDB+AOF 混合持久化，兼顾速度和安全性。
redis-Lettuce 框架因网络黑洞导致恢复时间变长
line_on_database的博客
12-19 933
生产上出现了两次 Redis 宿主机或者本身故障的情况，Redis 很快出现了切换，业务的影响面却在 15 分钟以上，使用的SDK 为 Lettuce外贸通这里需要将 Lettuce 升级为 6.3.0 + 版本并配置 tcp_user_timeout , Lettuce 详细参数见文档对于部分网卡宕机、网络分区故障等情况，概率性不会产生 RST。大多数的宕机，操作系统会在退出前给客户端发送 RST，因此这个问题不是切换或者宕机就必现；引用文章：详细文章net.ipv4.tcp_retries2 是 Lin
Redis Lua 脚本为什么天然具备原子性？
Knight
12-21 921
Redis Lua脚本的原子性源于Redis的单线程架构，整个脚本被视为一条不可分割的命令执行，确保脚本内的所有操作不会被其他客户端请求打断。这解决了高并发场景下的竞态问题，如库存扣减和一人一单等业务场景。相比MULTI/EXEC事务，Lua脚本提供更强的原子性保证且性能更优。但需要注意脚本不能跨Cluster节点执行，且过长的脚本会阻塞Redis服务。Lua脚本是Redis实现复杂原子操作的推荐方案。
RedisTemplate、StringRedisTemplate、RedisIndexedSessionRepository之间的区别？
2201_75642742的博客
12-19 1163
组件用途是否需手动操作数据格式典型场景通用 Redis 操作✅ 是二进制（默认）缓存对象、复杂数据结构字符串 Redis 操作✅ 是可读字符串缓存 JSON、计数器、简单 KVHTTP Session 存储到 Redis❌ 否（自动）Spring Session 内部格式分布式 Web 应用 Session 共享@Bean// 使用 JSON 序列化这样也能存可读的 JSON，但通常不如直接用灵活。
Redis —— 基本数据类型 String Hash List （二）
Li_769532的博客
12-17 848
Redis 基本数据类型 String Hash List
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值