Redis数据结构引擎：深入理解SDS与底层数据存储机制
【免费下载链接】redis 
项目地址: https://gitcode.com/gh_mirrors/redis/redis
本文深入解析Redis的核心数据结构引擎，重点探讨Simple Dynamic Strings（SDS）的设计原理与实现机制，以及Redis五种核心数据结构（String、List、Hash、Set、ZSet）的内存布局优化策略。文章详细分析了SDS相比传统C字符串的性能优势，包括O(1)复杂度长度获取、二进制安全性、空间预分配策略等核心特性。同时全面介绍了Redis如何通过ziplist、intset等紧凑数据结构实现内存效率最大化，并深入探讨了Redis的内存分配策略与碎片管理机制，包括zmalloc抽象层、碎片率计算和主动碎片整理等功能。
Simple Dynamic Strings (SDS)设计与实现原理
Redis中的Simple Dynamic Strings（SDS）是一个高效、安全的动态字符串库，它解决了传统C字符串的诸多限制，为Redis提供了高性能的字符串操作能力。SDS的设计哲学体现了Redis对性能和内存效率的极致追求。
SDS数据结构设计
SDS的核心数据结构设计简洁而高效，通过头部信息与数据缓冲区的巧妙结合，实现了O(1)复杂度的长度获取和空间预分配策略。
struct sdshdr {
unsigned int len; // 字符串实际长度
unsigned int free; // 剩余可用空间
char buf[]; // 柔性数组，存储字符串数据
};
这个设计的关键在于：
- len字段：记录字符串的实际长度，避免每次都需要遍历计算
- free字段：记录剩余可用空间，支持高效的追加操作
- buf柔性数组：存储实际的字符串数据，包含末尾的'\0'字符
内存布局与访问机制
SDS的内存布局采用了一种巧妙的设计，使得外部使用者只需要关心字符串数据本身，而内部管理信息对用户透明：
这种设计的优势在于：
- 二进制安全：可以存储包含'\0'字符的任意二进制数据
- 兼容C字符串：可以直接传递给标准C字符串函数
- 高效长度获取：O(1)时间复杂度获取字符串长度
核心操作实现原理
字符串创建与初始化
SDS提供了多种创建方式，每种都针对不同的使用场景进行了优化：
// 创建指定长度的SDS字符串
sds sdsnewlen(const void *init, size_t initlen) {
struct sdshdr *sh;
if (init) {
sh = zmalloc(sizeof(struct sdshdr) + initlen + 1);
} else {
sh = zcalloc(sizeof(struct sdshdr) + initlen + 1);
}
sh->len = initlen;
sh->free = 0;
if (initlen && init)
memcpy(sh->buf, init, initlen);
sh->buf[initlen] = '\0';
return sh->buf;
}
空间预分配策略
SDS采用了一种智能的空间预分配策略，在每次需要扩展空间时，根据当前长度决定预分配的大小：
sds sdsMakeRoomFor(sds s, size_t addlen) {
struct sdshdr *sh, *newsh;
size_t free = sdsavail(s);
size_t len, newlen;
if (free >= addlen) return s;
len = sdslen(s);
sh = (void*)(s - (sizeof(struct sdshdr)));
newlen = (len + addlen);
// 空间预分配策略
if (newlen < SDS_MAX_PREALLOC)
newlen *= 2; // 小字符串加倍分配
else
newlen += SDS_MAX_PREALLOC; // 大字符串线性增长
newsh = zrealloc(sh, sizeof(struct sdshdr) + newlen + 1);
newsh->free = newlen - len;
return newsh->buf;
}
这种策略的时间复杂度分析如下：
| 操作类型 | 时间复杂度 | 空间复杂度 | 说明 |
|---|---|---|---|
| 长度获取 | O(1) | O(1) | 直接读取len字段 |
| 追加操作 | 平摊O(1) | O(n) | 空间预分配策略优化 |
| 复制操作 | O(n) | O(n) | 需要完整复制数据 |
字符串拼接操作
SDS的字符串拼接操作充分利用了空间预分配策略，确保了高效的内存使用：
sds sdscatlen(sds s, const void *t, size_t len) {
struct sdshdr *sh;
size_t curlen = sdslen(s);
s = sdsMakeRoomFor(s, len); // 确保有足够空间
sh = (void*)(s - (sizeof(struct sdshdr)));
memcpy(s + curlen, t, len); // 复制数据
sh->len = curlen + len;
sh->free = sh->free - len;
s[curlen + len] = '\0'; // 确保以'\0'结尾
return s;
}
内存管理优化
SDS与Redis的内存分配器zmalloc深度集成，提供了精确的内存使用统计：
size_t sdsAllocSize(sds s) {
struct sdshdr *sh = (void*)(s - (sizeof(struct sdshdr)));
return sizeof(*sh) + sh->len + sh->free + 1; // 头部 + 已用 + 空闲 + '\0'
}
这种精确的内存统计使得Redis能够：
- 准确监控内存使用情况
- 实现精细化的内存回收策略
- 避免内存碎片问题
性能优势对比
与传统C字符串相比，SDS在多个维度上具有显著优势：
| 特性 | C字符串 | SDS | 优势说明 |
|---|---|---|---|
| 长度获取 | O(n) | O(1) | 避免遍历整个字符串 |
| 缓冲区溢出 | 易发生 | 安全 | 自动空间管理 |
| 二进制安全 | 不支持 | 支持 | 可存储任意数据 |
| 内存效率 | 固定大小 | 动态调整 | 减少内存浪费 |
| 追加操作 | O(n) | 平摊O(1) | 空间预分配策略 |
实际应用场景
在Redis内部，SDS被广泛应用于各种场景：
- 键值存储：所有字符串类型的键和值都使用SDS
- 网络协议：Redis协议解析使用SDS处理客户端命令
- 内部数据结构：列表、集合等复杂类型的元素存储
- 日志系统：慢查询日志、监控日志等文本处理
// Redis对象系统中SDS的使用示例
robj *createStringObject(const char *ptr, size_t len) {
// 创建包含SDS的Redis字符串对象
robj *o = zmalloc(sizeof(robj) + sizeof(struct sdshdr) + len + 1);
struct sdshdr *sh = (void*)(o + 1);
sh->len = len;
sh->free = 0;
memcpy(sh->buf, ptr, len);
sh->buf[len] = '\0';
o->type = REDIS_STRING;
o->encoding = REDIS_ENCODING_RAW;
o->ptr = sh->buf;
return o;
}
SDS的设计体现了Redis对性能和内存效率的极致追求，它不仅是字符串处理的工具，更是Redis高性能架构的重要基石。通过精巧的数据结构设计和智能的内存管理策略，SDS为Redis提供了安全、高效、灵活的字符串操作能力。
Redis五种核心数据结构的内存布局
Redis作为高性能的内存数据库，其核心优势在于精心设计的数据结构内存布局。每种数据结构都针对特定的使用场景进行了优化，通过不同的编码方式在内存使用效率和操作性能之间取得最佳平衡。本文将深入解析String、List、Hash、Set、ZSet五种核心数据结构在Redis内部的内存布局机制。
Redis对象基础结构
在深入具体数据结构之前，首先需要了解Redis的对象系统。所有Redis数据都以redisObject结构的形式存储：
typedef struct redisObject {
unsigned type:4; // 对象类型（String、List、Set、ZSet、Hash）
unsigned encoding:4; // 编码方式（raw、int、embstr、ziplist等）
unsigned lru:REDIS_LRU_BITS; // LRU时间信息
int refcount; // 引用计数
void *ptr; // 指向实际数据的指针
} robj;
这个基础结构为所有数据类型提供了统一的接口，同时通过encoding字段支持多种内部表示形式。
String类型的内存布局
String是Redis最基础的数据类型，支持三种编码方式：
1. REDIS_ENCODING_INT（整数编码）
当字符串可以表示为整数时，Redis直接使用整数编码：
内存布局：直接将整数值存储在ptr字段中，无需额外内存分配。
2. REDIS_ENCODING_EMBSTR（嵌入式字符串）
对于长度≤39字节的短字符串：
内存优势：对象头和字符串数据在单个内存块中，减少内存碎片和提高缓存 locality。
3. REDIS_ENCODING_RAW（原始字符串）
对于长字符串（>39字节）：
SDS（Simple Dynamic String）结构：
struct sdshdr {
unsigned int len; // 已使用长度
unsigned int free; // 未使用长度
char buf[]; // 柔性数组存储字符串
};
List类型的内存布局
List支持两种编码方式，根据元素数量和大小自动转换：
1. REDIS_ENCODING_ZIPLIST（压缩列表）
当满足以下条件时使用压缩列表：
- 所有字符串元素长度 < 64字节
- 元素数量 < 512个
压缩列表的优势：内存连续存储，减少指针开销，适合小元素存储。
2. REDIS_ENCODING_LINKEDLIST（双向链表）
当不满足压缩列表条件时转换为双向链表：
链表节点结构：
typedef struct listNode {
struct listNode *prev;
struct listNode *next;
void *value; // 指向redisObject
} listNode;
Hash类型的内存布局
Hash类型同样支持两种编码方式：
1. REDIS_ENCODING_ZIPLIST（压缩列表）
使用条件：
- 所有field和value字符串长度 < 64字节
- 键值对数量 < 512个
存储格式：field1, value1, field2, value2, ... 交替存储
2. REDIS_ENCODING_HT（哈希表）
当不满足压缩列表条件时使用字典：
哈希表采用链地址法解决冲突，支持渐进式rehash。
Set类型的内存布局
Set类型支持两种编码方式：
1. REDIS_ENCODING_INTSET（整数集合）
当所有元素都是整数时使用：
整数集合会根据元素大小自动升级编码，确保内存使用最优。
2. REDIS_ENCODING_HT（哈希表）
当包含非整数元素时使用字典，只使用key部分，value设置为NULL。
ZSet类型的内存布局
ZSet（有序集合）支持两种编码方式：
1. REDIS_ENCODING_ZIPLIST（压缩列表）
使用条件：
- 元素数量 < 128个
- 所有元素member长度 < 64字节
存储格式：member1, score1, member2, score2, ... 交替存储，按score排序
2. REDIS_ENCODING_SKIPLIST（跳跃表）
当不满足压缩列表条件时使用：
跳跃表结合了字典和跳跃表，既支持快速查询又支持范围操作。
内存布局优化策略
Redis通过以下策略优化内存使用：
- 编码自动转换：根据数据特征自动选择最合适的编码方式
- 共享对象：小整数和常用字符串对象共享，减少内存分配
- 内存预分配：SDS和压缩列表采用预分配策略减少内存重分配
- 渐进式Rehash：大哈希表rehash时分摊时间成本
性能对比分析
| 数据结构 | 编码方式 | 内存效率 | 查询性能 | 适用场景 |
|---|---|---|---|---|
| String | INT | 极高 | O(1) | 整数值 |
| String | EMBSTR | 高 | O(1) | 短字符串 |
| String | RAW | 中 | O(1) | 长字符串 |
| List | ZIPLIST | 高 | O(n) | 小列表 |
| List | LINKEDLIST | 中 | O(n) | 大列表 |
| Hash | ZIPLIST | 高 | O(n) | 小哈希 |
| Hash | HT | 中 | O(1) | 大哈希 |
| Set | INTSET | 极高 | O(log n) | 整数集合 |
| Set | HT | 中 | O(1) | 混合集合 |
| ZSet | ZIPLIST | 高 | O(n) | 小有序集 |
| ZSet | SKIPLIST | 中 | O(log n) | 大有序集 |
实际内存占用示例
通过一个具体示例展示不同编码方式的内存差异：
# 假设存储1000个整数的集合
int_set = set(range(1000)) # 使用INTSET编码，约8KB
# 存储1000个随机字符串的集合
str_set = set(f"item_{i}" for i in range(1000)) # 使用HT编码，约64KB
Redis的这种精细化的内存布局设计使得它在各种使用场景下都能保持优异的内存使用效率和操作性能，这也是Redis能够成为高性能内存数据库的关键因素之一。
数据编码优化：ziplist、intset等紧凑结构
Redis作为高性能内存数据库，在内存使用效率方面进行了深度优化。为了在保证性能的同时最大限度地减少内存占用，Redis实现了多种紧凑型数据结构，其中ziplist（压缩列表）和intset（整数集合）是最具代表性的两种编码优化方案。
ziplist：极致压缩的双向链表
ziplist是Redis中一种特殊编码的双向链表，专为内存效率而设计。它将字符串和整数值以紧凑的方式存储，整数直接编码为二进制而非字符序列，从而大幅减少内存使用。
ziplist的内存布局
ziplist的整体结构采用精心设计的二进制格式：
<zlbytes><zltail><zllen><entry><entry><zlend>
其中各字段的含义如下：
| 字段名 | 大小 | 描述 |
|---|---|---|
| zlbytes | 4字节 | 整个ziplist占用的字节数 |
| zltail | 4字节 | 最后一个entry的偏移量 |
| zllen | 2字节 | entry的数量 |
| entry | 可变 | 实际存储的数据条目 |
| zlend | 1字节 | 结束标记（255） |
ziplist entry的编码机制
每个entry都包含两个关键信息：前一个entry的长度和当前entry的编码信息。编码方式根据数据类型智能选择：
ziplist的优势与适用场景
ziplist的主要优势体现在：
- 内存效率极高：通过二进制编码和紧凑存储，相比普通链表可节省50-70%内存
- 缓存友好：连续内存布局提高CPU缓存命中率
- 双向遍历：支持O(1)时间的头尾操作
适用场景包括：
- 小型列表、哈希表和有序集合
- 元素数量较少且值较小的集合
- 需要极致内存优化的场景
intset：有序整数集合的紧凑存储
intset是专门为存储整数而设计的紧凑数据结构，它保证元素有序且无重复，采用统一的编码格式存储所有整数。
intset的核心结构
intset的结构定义简洁而高效：
typedef struct intset {
uint32_t encoding; // 编码方式
uint32_t length; // 元素数量
int8_t contents[]; // 实际存储的内容
} intset;
编码升级机制
intset支持三种编码级别，可根据存储的数值范围自动升级：
| 编码类型 | 数值范围 | 每个元素占用字节 |
|---|---|---|
| INTSET_ENC_INT16 | -32,768 到 32,767 | 2字节 |
| INTSET_ENC_INT32 | -2,147,483,648 到 2,147,483,647 | 4字节 |
| INTSET_ENC_INT64 | 超大整数范围 | 8字节 |
intset的搜索算法
intset使用二分查找算法确保高效的搜索性能：
static uint8_t intsetSearch(intset *is, int64_t value, uint32_t *pos) {
int min = 0, max = intrev32ifbe(is->length)-1, mid = -1;
int64_t cur = -1;
while(max >= min) {
mid = ((unsigned int)min + (unsigned int)max) >> 1;
cur = _intsetGet(is,mid);
if (value > cur) {
min = mid+1;
} else if (value < cur) {
max = mid-1;
} else {
break;
}
}
// ... 返回结果
}
配置参数与自动转换
Redis提供了灵活的配置参数来控制这些紧凑结构的使用：
| 配置项 | 默认值 | 描述 |
|---|---|---|
| set-max-intset-entries | 512 | intset最大元素数量 |
| zset-max-ziplist-entries | 128 | ziplist最大元素数量 |
| zset-max-ziplist-value | 64 | ziplist单个元素最大字节数 |
当集合的元素数量或元素大小超过这些阈值时，Redis会自动将数据结构转换为更通用的实现（如哈希表、跳表等），以平衡内存使用和操作性能。
性能对比与最佳实践
通过实际测试，紧凑结构在特定场景下展现出色性能：
| 操作类型 | ziplist性能 | 普通结构性能 | 优势 |
|---|---|---|---|
| 内存占用 | 极低 | 较高 | 节省50-70% |
| 遍历速度 | 快 | 中等 | 缓存友好 |
| 随机访问 | 慢 | 快 | 需要顺序访问 |
最佳实践建议：
- 对于小型集合，优先使用紧凑结构
- 根据实际数据特征调整配置参数
- 监控内存使用和性能指标
- 在内存敏感的场景中充分利用这些优化
Redis的ziplist和intset体现了在内存数据库设计中空间与时间的精妙平衡，通过智能的编码策略和自动转换机制，为不同规模和工作负载的数据提供了最优的存储方案。
内存分配策略与碎片管理机制
Redis作为高性能内存数据库，其内存管理机制直接关系到系统性能和稳定性。Redis采用了多层次的内存分配策略和碎片管理机制，确保在频繁的内存分配和释放操作中保持高效性能。
内存分配器架构
Redis支持多种内存分配器，通过编译时配置可以选择不同的底层分配器：
Redis默认推荐使用jemalloc，因为它在处理内存碎片方面表现优异。可以通过编译选项选择不同的分配器：
# 使用jemalloc编译
make MALLOC=jemalloc
# 使用libc编译
make MALLOC=libc
# 使用tcmalloc编译
make MALLOC=tcmalloc
zmalloc内存管理抽象层
Redis在底层分配器之上构建了zmalloc抽象层，提供了统一的内存管理接口：
void *zmalloc(size_t size); // 分配内存
void *zcalloc(size_t size); // 分配并清零内存
void *zrealloc(void *ptr, size_t size); // 重新分配内存
void zfree(void *ptr); // 释放内存
size_t zmalloc_used_memory(void); // 获取已使用内存大小
内存分配实现细节
zmalloc在分配内存时会根据不同的分配器特性进行处理：
void *zmalloc(size_t size) {
void *ptr = malloc(size+PREFIX_SIZE);
if (!ptr) zmalloc_oom_handler(size);
#ifdef HAVE_MALLOC_SIZE
update_zmalloc_stat_alloc(zmalloc_size(ptr));
return ptr;
#else
*((size_t*)ptr) = size;
update_zmalloc_stat_alloc(size+PREFIX_SIZE);
return (char*)ptr+PREFIX_SIZE;
#endif
}
其中关键特性包括：
- 前缀空间管理：对于不支持
malloc_size的系统，zmalloc会在分配的内存块前添加一个前缀来存储分配大小 - 内存对齐：确保分配的内存按照
sizeof(PORT_LONG)进行对齐，提高访问效率 - 内存统计：实时跟踪已分配的内存总量
内存碎片管理机制
碎片率计算
Redis通过zmalloc_get_fragmentation_ratio()函数计算内存碎片率：
/* Fragmentation = RSS / allocated-bytes */
float zmalloc_get_fragmentation_ratio(size_t rss) {
return (float)rss/zmalloc_used_memory();
}
碎片率公式为：
内存碎片率 = 实际物理内存使用量(RSS) / Redis分配的内存总量
这个比值反映了内存碎片的严重程度：
- 比值接近1.0：碎片化程度低
- 比值大于1.0：存在内存碎片
- 比值越大：碎片化越严重
碎片监控与统计
Redis在INFO命令中提供内存碎片信息：
# Memory
used_memory:1030552
used_memory_human:1006.30K
used_memory_rss:2072576
used_memory_rss_human:2.00M
mem_fragmentation_ratio:2.01
关键指标说明：
| 指标 | 描述 | 正常范围 |
|---|---|---|
| used_memory | Redis分配的内存总量 | - |
| used_memory_rss | 操作系统视角的内存使用量 | - |
| mem_fragmentation_ratio | 内存碎片率 | 1.0-1.5 |
内存分配策略优化
1. 分配器选择策略
Redis根据不同场景推荐不同的分配器：
| 分配器 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| jemalloc | 碎片管理优秀，多线程性能好 | 内存开销稍大 | 生产环境首选 |
| tcmalloc | 多线程性能极佳 | 碎片管理一般 | 高并发场景 |
| dlmalloc | 内存开销小 | 碎片管理较差 | 内存受限环境 |
| libc malloc | 兼容性好 | 性能一般，碎片多 | 测试环境 |
2. 内存对齐策略
Redis通过内存对齐减少碎片：
#define update_zmalloc_stat_alloc(__n) do { \
size_t _n = (__n); \
if (_n&(sizeof(PORT_LONG)-1)) _n += sizeof(PORT_LONG)-(_n&(sizeof(PORT_LONG)-1)); \
// ... 统计逻辑
} while(0)
这种对齐策略确保每个内存块都是PORT_LONG大小的倍数，提高了内存访问效率并减少了内部碎片。
3. 线程安全机制
Redis支持线程安全的内存分配统计：
void zmalloc_enable_thread_safeness(void) {
zmalloc_thread_safe = 1;
}
启用线程安全后，内存统计操作会使用原子操作或互斥锁来保证数据一致性。
碎片预防与处理策略
1. 配置优化
通过Redis配置减少碎片产生：
# 设置最大内存限制，触发内存淘汰机制
maxmemory 1gb
# 使用合适的淘汰策略
maxmemory-policy allkeys-lru
# 设置内存碎片整理阈值
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100
2. 主动碎片整理
Redis 4.0+版本引入了主动内存碎片整理功能：
3. 内存回收策略
采用合适的内存回收策略减少碎片：
- 定期重启：在低峰期重启Redis实例
- 数据分片：使用Redis Cluster分散内存压力
- 监控告警：设置碎片率监控，及时干预
性能优化实践
内存分配性能对比
不同分配器在Redis中的性能表现：
| 操作类型 | jemalloc | tcmalloc | libc malloc |
|---|---|---|---|
| 分配速度 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 释放速度 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| 碎片管理 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐ |
| 多线程 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
最佳实践建议
- 生产环境：优先使用jemalloc，配置合适的最大内存限制
- 监控配置：设置内存碎片率告警阈值（建议1.5）
- 版本选择：使用Redis 4.0+版本以获得主动碎片整理功能
- 数据设计：避免大量小对象的频繁分配和释放
通过这套完善的内存分配策略和碎片管理机制，Redis能够在高并发场景下保持稳定的内存使用效率，为高性能数据存储提供坚实基础。
总结
Redis通过精心设计的数据结构引擎实现了高性能与内存效率的完美平衡。SDS作为基础字符串处理机制，解决了传统C字符串的诸多限制，为Redis提供了安全高效的字符串操作能力。五种核心数据结构通过智能的编码转换机制，在不同数据规模下自动选择最优的内存布局方案。ziplist和intset等紧凑结构在特定场景下大幅减少内存占用，而多层次的内存分配策略和碎片管理机制确保了系统在长期运行中的稳定性。这些设计体现了Redis在空间与时间效率上的深度优化，使其成为高性能内存数据库的典范。理解这些底层机制对于Redis性能调优和故障排查具有重要意义。
【免费下载链接】redis 项目地址: https://gitcode.com/gh_mirrors/redis/redis
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
