首页 > 数据库 >Redis数据编码详解

Redis数据编码详解

来源：互联网 2026-07-07 09:14:00

struct redisObject { unsigned type:4; // [0-3 bit] 对象类型 (如 String) unsigned encoding:4; // [4-7 bit] 编码方式 (如 int/embstr/raw) unsigned lru:24; // [8-31

struct redisObject {    unsigned type:4;       // [0-3 bit] 对象类型 (如 String)    unsigned encoding:4;   // [4-7 bit] 编码方式 (如 int/embstr/raw)    unsigned lru:24;       // [8-31 bit] 缓存淘汰数据    int refcount;          // [32-63 bit] 引用计数 (4字节)    void *ptr;             // [64-127 bit] 关键指针 (8字节)};

String

Redis 的 String 类型，表面上是一个简单的字符串，但在底层却包含三种不同的编码方式：int、embstr 和 raw。之所以这样设计，是因为 String 的数据大小差异较大，Redis 需要根据内容为整数还是文本、长度是短还是长，动态选择最优存储方案，从而在内存占用和性能之间取得平衡。

Redis数据编码详解

长期稳定更新的攒劲资源： >>>点此立即查看<<<

这三种编码都统一在 redisObject 这个“外壳”之下，通过 encoding 字段区分当前使用的编码类型。

struct sdshdr8 {    uint8_t len;    /* 已使用长度 */    uint8_t alloc;  /* 总分配空间（不含头和 ） */    unsigned char flags; /* 类型标志（如 sdshdr8, sdshdr16 等） */    char buf[];     /* 实际字节数组 */};

1. int编码：直接存储整数

当一个字符串对象保存的是整数值，并且该整数可以用 long 类型（8字节有符号整数）表示时，Redis 会采用 int 编码。此时，Redis 不会额外分配 SDS 空间，而是直接将整数值存储在 redisObject 结构体的 ptr 指针字段中（通过强制类型转换实现）。

  • 共享对象优化：Redis 启动时会预先创建 0～9999 这 10,000 个整数对象。如果存储的值落在这个范围内，所有 Key 都会指向同一个物理内存地址，引用计数加 1，内存开销几乎为零。这种优化在很多场景中都能见到，但 Redis 做到了极致。
  • 适用场景：计数器、ID 存储等纯数值场景，内存效率极高。

2. embstr编码：嵌入式短字符串

当字符串的长度小于等于 44 字节时，Redis 会切换为 embstr 编码。其核心目的是最大限度压榨小对象的性能。

  • 物理特征：redisObject 和 sdshdr（SDS 头部及数据）在内存中连续存储，通过一次 malloc 申请完成。这意味着分配和释放都只需一次系统调用，内存布局十分紧凑。
  • 核心逻辑：
    • 只读性：该编码是只读的。任何修改操作（如 APPEND）都会强制将其升级为 raw 编码，因为连续内存块无法在原位置安全扩展。
    • 高性能：由于内存连续，CPU 缓存命中率极高，读写速度非常快。
  • 计算门槛：44 字节这个限制是如何得出的？简单计算：一个 redisObject 占 16 字节，sdshdr8 占 3 字节，再加一个结束符 占 1 字节，剩余 44 字节用于数据，整个对象恰好塞进内存分配器的 64 字节 槽位，不浪费任何空间。

3. raw编码：常规长字符串

当字符串长度大于 44 字节，或者对 embstr 执行了修改操作时，Redis 会采用 raw 编码。这种方式适合处理较大的数据。

  • 物理特征：redisObject 和 sdshdr 分布在两块不连续的内存空间中。ptr 指针指向独立的 SDS 区域。
  • 核心逻辑：
    • 可扩展性：适合存储长文本、二进制数据或频繁修改的字符串，因为可以灵活重新分配内存。
    • 分配代价：创建或销毁对象需要两次 malloc 或 free，开销比 embstr 略大。
  • 适用场景：JSON 数据、序列化后的对象、较大的文本内容等，处理起来没有压力。

List

Redis3.2之前：ZipList/LinkedList

在 Redis 3.2 之前，List 的实现比较直接：数据量小时使用 ZipList（压缩列表）——连续内存以节省空间；数据量大或字符串较长时，直接使用 LinkedList（双向链表）——通过指针实现灵活增删。但缺点也很明显：每个节点需要两个 8 字节的指针（prev/next），且内存碎片较多。

Redis3.2之后：QuickList

RedisObject 中的 *ptr 指向 quicklist 对象

typedef struct quicklist {    quicklistNode *head;      /* 指向头节点 */    quicklistNode *tail;      /* 指向尾节点 */    unsigned long count;      /* 所有元素总数 */    unsigned long len;        /* 节点（车厢）总数 */    int fill : 16;            /* 节点填充因子 */    unsigned int compress : 16; /* 压缩深度 */} quicklist;typedef struct quicklistNode {    struct quicklistNode *prev; /* 前驱指针 */    struct quicklistNode *next; /* 后继指针 */    unsigned char *zl;          /* 指向物理内存中的连续块 (ZipList/Listpack) */    unsigned int sz;            /* 连续块占用的总字节数 */    unsigned int count : 16;    /* 连续块包含的元素个数 */    // ... 其他标志位} quicklistNode;

Set

Redis 的 Set（集合） 编码设计遵循“从小到大”的进化逻辑。其物理实现主要在 IntSet（整数集合）、Listpack（紧凑列表，Redis 7.2+） 和 Hashtable（哈希表） 之间切换。核心思想可以概括为：如果全是小整数，就用数组排序存储；如果包含字符串，则使用哈希表。

1. 物理结构：intset(整数集合)

当集合满足以下两个条件时，Redis 优先使用 intset：

  1. 集合内所有成员均为整数。
  2. 成员数量小于配置参数 set-max-intset-entries（默认 512 个）。

内存布局与查找逻辑

intset 是一块绝对连续的内存空间。

  • 物理存储：内部是一个有序数组，支持 int16_t、int32_t 或 int64_t 编码。
  • 有序性：元素在数组内按从小到大严格排序。
  • 查找算法：使用 二分查找（Binary Search），时间复杂度为 O(log N)。
  • 升级逻辑：当新插入的整数超出当前位宽（比如原本存 int16，现在要存 int32）时，会触发整块内存的重新分配和数据迁移。需要注意，这个过程不可逆（不支持降级）——一旦升级到更高位宽，即使后续所有数字都能用低位宽表示，也不会降级，这是为了保持实现简单和性能稳定。

2. 物理结构：listpack(紧凑列表)

这是 Redis 7.2 引入的新物理层。在旧版本中，集合只要出现一个字符串就会直接扩容为 dict，而 listpack 充当了中间的缓冲带，避免过早转型。

  • 触发场景：集合中包含字符串，但成员数量和单个字符串长度未达到 set-max-listpack-entries 和 set-max-listpack-value 阈值。
  • 物理特征：连续字节流存储，非常紧凑。
  • 性能权衡：查找复杂度退化为 O(N)（顺序遍历），但由于数据规模极小，其内存利用率远高于 dict，并且连续内存对 CPU 缓存友好，在小数据量下完全抵消了 O(N) 的劣势。

3. 物理结构：dict(字典 / 逻辑名称 HashTable)

当集合规模超过阈值，或者包含长字符串时，Redis 会使用 dict 作为最终物理载体。

物理映射与内存布局

此时 redisObject->ptr 指向一个真实的 dict 结构体实例。

  • Key (键)：存储集合的成员，指向一个 SDS 字符串对象。
  • Value (值)：物理上统一设置为 NULL 指针。因为集合只关心成员是否存在，不需要存储值。
  • 唯一性保证：直接利用 dict 自身的哈希碰撞处理和 Key 唯一性逻辑实现集合去重。
  • 性能特征：查找复杂度为 O(1)。支持渐进式 Rehash，在数据量极大时仍能保持稳定的响应速度。

4. 宏观物理映射：RedisObject 的指向

对于 Set 来说，redisObject 的包装方式如下：

字段IntSet 编码Hashtable 编码
typeOBJ_SETOBJ_SET
encodingOBJ_ENCODING_INTSETOBJ_ENCODING_HT
ptr 指向一整块连续的 intset 结构一个复杂的 dict 字典结构

ZSet

Redis 的 ZSet（有序集合） 在底层编码上设计最为复杂，因为它必须同时满足两个核心需求：O(1) 成员查分（按成员查分数）和 O(log N) 按分数排序/范围检索。物理实现主要分为两个阶段：listpack 和 dict + zskiplist。

1. 紧凑阶段：listpack(紧凑列表)

当 ZSet 满足以下两个条件时，Redis 使用 listpack 编码（OBJ_ENCODING_LISTPACK）：

  1. 成员数量小于 zset-max-listpack-entries（默认 128）。
  2. 所有成员字符串长度小于 zset-max-listpack-value（默认 64 字节）。

物理存储逻辑

在 listpack 内部，成员（Member）和分值（Score）存储为两个相邻的 Entry：

  • 布局：[Member1, Score1, Member2, Score2, ...]
  • 有序性：内部元素按分值（Score）从小到大严格排序。
  • 性能特征：由于是连续内存，插入和查找涉及 O(N) 的顺序遍历及内存搬迁。但在小数据量下，这种结构的 CPU 缓存命中率极高，且省去了复杂的指针开销，实现简单。

2. 进化阶段：zset结构体 (跳表 + 字典)

当数据量突破阈值后，redisObject->ptr 会指向一个专门的 zset 结构体。这是一种双重物理结构的组合：

typedef struct zset {    dict *dict;          /* 成员 -> 分值的哈希表 */    zskiplist *zsl;      /* 按分数排序的跳跃表 */} zset;

A. 物理组件一：dict(字典)

  • 作用：实现 O(1) 复杂度的 ZSCORE 操作。给定成员名，即可立即查到分数。
  • 逻辑：Key 是成员（SDS），Value 是分值（double）。
  • 必要性：如果没有 dict，查找一个成员的分数需要遍历跳表，复杂度为 O(log N)，对于高频率的查分操作来说不够快。

B. 物理组件二：zskiplist(跳跃表)

  • 作用：实现高效的范围查询（ZRANGE）和排名计算（ZRANK）。
  • 逻辑：节点按分数排序。每个节点包含多个层级的指针，支持快速跳跃寻址，插入和删除也能保持对数级别复杂度。
  • 性能：平均查找复杂度为 O(log N)。

3. 内存优化：SDS 的“引用共享”

你可能会担心：同一个成员既存在 dict 里，又存在 zskiplist 里，是否浪费内存？

物理真相：dict 的 Key 和 zskiplistNode 的 ele 指向的是同一个物理内存地址（同一个 SDS 对象）。Redis 只是在两个数据结构中各存了一个指针，实际数据只存储一份。这种设计通过增加少量指针开销（每个节点约几十字节），换取了两个维度的极致查询速度——这个取舍非常划算。

4. 物理特性对比表

物理结构逻辑编码 (Encoding)核心优势算法复杂度内存特征
listpackLISTPACK极致节省内存O(N) (查找/插入)连续内存，无碎片
zset (复合)SKIPLIST全能性能查分 O(1)，范围 O(log N)双重索引，指针较多

5. 状态转换逻辑

ZSet 的转换通常是单向不可逆的：一旦数据量超过阈值，listpack 会被拆解，重新装载进一个新的 dict 和 zskiplist 中。原因：从复杂的双重结构回退到连续内存块涉及大规模的内存重分配和 CPU 计算，收益不抵成本。所以一旦升级，就安心使用“重武器”。

Hash

Redis 的 Hash（哈希） 结构在底层编码的设计上，逻辑与 ZSet 相似：数据量小时采用紧凑的连续内存，数据量大时进化为散列表。目前的物理实现主要分为 listpack 和 dict 两种。

1. 紧凑编码：listpack(紧凑列表)

当 Hash 结构满足以下两个条件时，Redis 使用 listpack 存储（编码名称为 OBJ_ENCODING_LISTPACK）：

  1. 哈希中字段（Field）的数量小于 hash-max-listpack-entries（默认 512 个）。
  2. 所有字段名和值的长度都小于 hash-max-listpack-value（默认 64 字节）。

物理存储逻辑

在 listpack 的字节流中，Field 和 Value 作为两个相邻的 Entry 存储：

  • 布局：[Field1, Value1, Field2, Value2, ...]
  • 查找方式：完全依靠顺序遍历。由于内存绝对连续，CPU 在读取时可以利用预取机制（Prefetching），在小规模数据下速度极快。
  • 内存优势：没有指针开销，没有内存对齐的空隙，空间利用率达到极致。如果存储几十个短字段，用 listpack 几乎不浪费一个字节。

2. 散列编码：dict(字典)

一旦数据量突破阈值，或者某个 Value 太长，Redis 就会将物理结构转换为 dict（编码名称为 OBJ_ENCODING_HT）。

物理实现逻辑

此时 redisObject->ptr 指向一个真实的 dict 结构体：

  • Key (键)：存储的是 Hash 的字段名（Field），物理上是一个 SDS 对象。
  • Value (值)：存储的是 Hash 的字段值（Value），物理上同样是一个 SDS 对象。
  • 冲突处理：使用拉链法（链地址法）解决哈希冲突。
  • 性能特征：查找、插入和删除的复杂度均为 O(1)。对于大规模 Hash 来说，这是标准配置。

侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述

相关攻略

更多

同类更新

更多

热游推荐

更多

精彩专题

更多
手游 专题 攻略 App下载 web3
返回首页 回到顶部
湘ICP备2026025700号-3 湘公网安备 43070302000280号
All Rights Reserved
本站为非盈利网站，不接受任何广告。本站所有软件，都由网友
上传，如有侵犯你的版权，请发邮件给xiayx666@163.com
抵制不良色情、反动、暴力游戏。注意自我保护，谨防受骗上当。
适度游戏益脑，沉迷游戏伤身。合理安排时间，享受健康生活。