Redis数据结构-动态字符串
一、前言：为什么 Redis 要“再造”一个字符串？
Redis 是用 C 语言编写的，但却没有直接使用 C 语言的原生字符串（以\0结尾的char*）。这是为什么？
💡核心原因：
C 字符串在性能、安全性和功能上，无法满足 Redis 作为高性能数据库的需求！
为此，Redis 自研了一种名为SDS（Simple Dynamic String，简单动态字符串）的抽象类型，并将其作为 Redis 的默认字符串表示。
本文将带你：
- 拆解 SDS 的底层结构
- 对比 SDS 与 C 字符串的 5 大差异
- 揭秘 Redis 如何通过 SDS 实现 O(1) 长度获取、杜绝缓冲区溢出、高效内存管理
二、SDS 是什么？结构定义大揭秘
2.1 核心思想
SDS 在 C 字符串的基础上，增加了一个 header，用于存储元信息。
2.2 Redis 5.0+ 的 SDS 结构（优化版）
为了节省内存，Redis 针对不同长度的字符串，定义了5 种 header 结构：
// 通用结构（概念模型） struct __attribute__ ((__packed__)) sdshdr { uint8_t flags; // 低3位表示类型，高5位未用 char buf[]; // 柔性数组，存放实际字符串 }; // 具体实现（根据字符串长度选择） struct __attribute__ ((__packed__)) sdshdr5 { unsigned char flags; // 3bit type + 5bit len (仅用于len<32) char buf[]; }; struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; // 已使用字节数 uint8_t alloc; // 总分配字节数（不含header和\0） unsigned char flags; char buf[]; }; struct __attribute__ ((__packed__)) sdshdr16 { uint16_t len; uint16_t alloc; ... }; struct __attribute__ ((__packed__)) sdshdr32 { uint32_t len; uint32_t alloc; ... }; struct __attribute__ ((__packed__)) sdshdr64 { uint64_t len; uint64_t alloc; ... };✅关键字段说明：
len：字符串的实际长度（不包括结尾的\0）alloc：已分配的总容量（buf数组的大小 =alloc + 1，多出的 1 字节用于\0）flags：标识当前使用的是哪种 header（如sdshdr8）
2.3 一个直观的例子
假设我们执行：
SET name "Redis"Redis 会创建一个 SDS，其内存布局如下（以sdshdr8为例）：
| 字段 | 值 | 说明 |
|---|---|---|
len | 5 | "Redis" 长度为 5 |
alloc | 5 | 初始分配 5 字节（无多余空间） |
flags | 1 | 表示使用sdshdr8类型 |
buf | 'R','e','d','i','s','\0' | 实际数据 + C 风格结尾 |
📌注意：SDS兼容 C 字符串，因此
buf末尾依然保留\0，可以直接传给 C 库函数（如printf）。
三、SDS vs C 字符串：五大核心优势
| 特性 | C 字符串 | SDS | SDS 的优势 |
|---|---|---|---|
| 1. 获取长度 | O(n)（需遍历到\0） | O(1)（直接读len） | 性能飞跃，尤其对长字符串 |
| 2. 缓冲区安全 | 易溢出（如strcat越界） | 自动检查并扩容 | 杜绝安全漏洞 |
| 3. 内存重分配 | 每次修改都可能realloc | 智能预分配/惰性释放 | 减少系统调用，提升性能 |
| 4. 二进制安全 | 不能包含\0（会被截断） | 可存储任意二进制数据 | 支持图片、序列化对象等 |
| 5. 兼容性 | - | 兼容 C 字符串函数 | 无缝集成现有生态 |
四、深度剖析：SDS 的三大内存优化策略
4.1 策略 1：空间预分配（sdsMakeRoomFor）
当对 SDS 进行增长操作（如append）时，Redis 不仅分配所需空间，还会额外预分配：
- 若新长度 < 1MB：预分配等量的未使用空间
（例：追加后 len=100 → alloc=200） - 若新长度 ≥ 1MB：预分配1MB的未使用空间
效果：N 次追加操作，最多触发 N 次内存重分配（通常远少于 N）。
4.2 策略 2：惰性空间释放（sdsRemoveFreeSpace）
当对 SDS 进行缩短操作（如trim）时，Redis不立即释放内存，而是更新len，保留alloc。
- 好处：后续若再次增长，可直接使用预留空间，避免
realloc。 - 手动释放：可通过
sdsRemoveFreeSpaceAPI 强制释放。
4.3 策略 3：类型自适应（Header 优化）
- 短字符串（< 32字节）：用
sdshdr5，无len/alloc字段，长度存于flags，极致省空间。 - 长字符串：自动升级到
sdshdr16/32/64，避免溢出。
效果：小 Key 场景下，内存占用比 C 字符串仅多 1~3 字节！
五、SDS 在 Redis 中的应用场景
SDS 不仅是字符串值的载体，更是 Redis 内部的通用缓冲区：
- 键（Key）和值（Value）：所有字符串对象底层都是 SDS。
- AOF 缓冲区：写 AOF 文件前，命令先存入 SDS 缓冲区。
- 客户端输入缓冲区：存储客户端发来的命令。
- Lua 脚本：脚本内容以 SDS 形式存储。
✅一句话总结：
“SDS 是 Redis 内存世界的基石。”
六、动手实验：观察 SDS 的行为
6.1 查看字符串内部编码
# 创建一个字符串 > SET msg "Hello" OK # 查看底层编码（应为 embstr 或 raw，底层都是 SDS） > OBJECT ENCODING msg "embstr" # 追加内容，触发扩容 > APPEND msg ", World!" (integer) 13 # 再次查看（可能变为 raw） > OBJECT ENCODING msg "raw"6.2 验证二进制安全
# 存储包含 \0 的二进制数据 > SET bin "\x00\xFF\x00" OK # 获取完整数据（长度为3） > GET bin "\x00\xff\x00" > STRLEN bin (integer) 3C 字符串在此会返回长度 0！
七、结语
感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！