358 lines
16 KiB
Markdown
358 lines
16 KiB
Markdown
---
|
||
tags: [Redis, 底层数据结构, SDS, 字符串]
|
||
create time: 2026-05-26 13:41
|
||
author: hhs
|
||
---
|
||
|
||
# SDS（Simple Dynamic Strings）
|
||
|
||
## 概述
|
||
|
||
> [!tip] Redis 为什么不用 C 语言自带的字符串？
|
||
> C 语言的字符串就是一个以 `\0` 结尾的 `char` 数组——简单，但在 Redis 这种高性能场景下，有一堆致命缺陷：求长度要 O(N) 遍历、二进制数据不能存、拼接可能缓冲区溢出……
|
||
>
|
||
> SDS 就是 Redis 对这些问题的"全面回答"。它**兼容 C 字符串**（末尾保留 `\0`），但在头部加了元数据，把常见的痛点全抹掉了。
|
||
|
||
SDS 是 Redis 中**最基础、使用最广泛**的数据结构——不仅仅是 String 类型的底层实现，**所有 Redis 键（key）都是 SDS**，Hash 的 field 名、AOF 缓冲区、客户端输入缓冲区……到处都有它的身影。
|
||
|
||
## 一、C 字符串的四大痛点
|
||
|
||
> [!question] 直接用 `char *` 不行吗？
|
||
> 我们来逐个看看 C 原生字符串在 Redis 场景下的问题：
|
||
|
||
| 痛点 | 说明 | SDS 怎么解决 |
|
||
|------|------|-------------|
|
||
| **O(N) 求长度** | `strlen()` 必须遍历到 `\0`，百万字符的 value 每次求长度都线性扫描 | `len` 字段记录长度，**O(1)** |
|
||
| **二进制不安全** | `\0` 是结束符，图片、序列化数据里出现 `\0` 就被截断 | 用 `len` 判断结束，`\0` 仅用于兼容 C 函数 |
|
||
| **缓冲区溢出** | `strcat()` 不检查目标空间，拼接可能写越界 | API 自动检查空间，不够就扩容 |
|
||
| **重复内存分配** | 修改字符串长度就要 `realloc`，N 次修改 = N 次系统调用 | 空间预分配 + 惰性释放 |
|
||
|
||
> [!insight] SDS 不是"一种"结构，而是一族结构
|
||
> Redis 根据字符串长度使用不同大小的 header（sdshdr5/8/16/32/64），短字符串用更小的 header，极致省内存——这是 SDS 最巧妙的设计之一。
|
||
|
||
## 二、SDS 的内存布局
|
||
|
||
### 基本结构
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph SDS["SDS 内存布局"]
|
||
direction LR
|
||
H["header: len + alloc + flags"]
|
||
B["buf[]: 实际字符串数据, 末尾保留 '\\0'"]
|
||
H --> B
|
||
end
|
||
|
||
classDef header fill:#e1f5fe,stroke:#2196f3
|
||
classDef buf fill:#fff3e0,stroke:#ff9800
|
||
class H header
|
||
class B buf
|
||
```
|
||
|
||
```c
|
||
// 以 sdshdr8 为例（适用于字符串长度 < 256 字节的情况）
|
||
// 注意：len 和 alloc 都是 unsigned，能表示 0~255
|
||
struct __attribute__ ((__packed__)) sdshdr8 {
|
||
uint8_t len; // 已使用的字节数（不含末尾 '\0'）
|
||
uint8_t alloc; // 分配的总字节数（不含末尾 '\0' 和 header）
|
||
unsigned char flags; // 类型标志，低 3 位标识 sdshdr 类型
|
||
char buf[]; // 柔性数组，实际数据从这里开始
|
||
};
|
||
```
|
||
|
||
> [!question] 为什么 `buf[]` 末尾要保留 `\0`？
|
||
> 为了**兼容 C 标准库函数**。SDS 可以直接把 `buf` 传给 `printf`、`strcmp` 等函数，不需要额外拷贝或转换。这是一个务实的工程决策——既能用 C 生态的库，又不受 C 字符串的限制。
|
||
|
||
> [!tip] `__attribute__((packed))` 的作用
|
||
> 编译器默认会对结构体做**内存对齐**（padding），`packed` 告诉编译器"不要加任何填充字节"。SDS header 可能只有 3~5 字节，对齐填充会浪费大量空间。
|
||
|
||
> [!note] 版本历史：这套体系从 Redis 3.2 开始
|
||
> Redis 3.2 之前只有一个统一的 `struct sdshdr`（8B header，`len` 和 `alloc` 都是 `int`），无论字符串多短都要付出 8B header 的代价。antirez 在 3.2 引入了 5 级 header + `packed` 属性，**让短字符串的内存开销直接砍掉了几个字节**。在亿级 key 的场景下，这个优化可以节省 GB 级内存。
|
||
|
||
### 五种 sdshdr 类型
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
S["SDS 字符串"] --> Q{"字符串长度?"}
|
||
Q -->|"0 ~ 31"| T5["sdshdr5, flags 1B, 无 len/alloc 字段"]
|
||
Q -->|"0 ~ 255"| T8["sdshdr8, 3B header, len + alloc 各 1B"]
|
||
Q -->|"0 ~ 65535"| T16["sdshdr16, 4B header, len + alloc 各 2B"]
|
||
Q -->|"0 ~ 4294967295"| T32["sdshdr32, 8B header, len + alloc 各 4B"]
|
||
Q -->|"> 4GB"| T64["sdshdr64, 16B header, len + alloc 各 8B"]
|
||
|
||
classDef tiny fill:#e8f5e9,stroke:#4caf50
|
||
classDef small fill:#e1f5fe,stroke:#2196f3
|
||
classDef medium fill:#fff3e0,stroke:#ff9800
|
||
classDef large fill:#ffebee,stroke:#f44336
|
||
classDef check fill:#f3e5f5,stroke:#9c27b0
|
||
class T5 tiny
|
||
class T8 small
|
||
class T16 medium
|
||
class T32,T64 large
|
||
class Q check
|
||
```
|
||
|
||
| 类型 | `len` 占用 | `alloc` 占用 | flags 占用 | header 总大小 | 最大长度 |
|
||
|------|:---------:|:----------:|:--------:|:-----------:|:-------:|
|
||
| `sdshdr5` | 0B | 0B | 1B | **1B** | 31B |
|
||
| `sdshdr8` | 1B | 1B | 1B | **3B** | 255B |
|
||
| `sdshdr16` | 2B | 2B | 1B | **5B** | 64KB |
|
||
| `sdshdr32` | 4B | 4B | 1B | **9B** | 4GB |
|
||
| `sdshdr64` | 8B | 8B | 1B | **17B** | 2^64B |
|
||
|
||
> [!question] sdshdr5 为什么没有 `len` 和 `alloc` 字段？
|
||
> 因为它只存 0~31 字节的超短字符串——长度信息直接**编码在 flags 的高 5 位里**，连 `len` 字段都省了。Redis 在"能省一个字节就省一个字节"这件事上做到了极致。
|
||
>
|
||
> `sdshdr5` 的 `flags` 高 5 位就是长度值，低 3 位是类型标志。一个 32 字节的 header 变成 1 字节——在 Redis 动辄存上亿 key 的场景下，光这一项就能省几个 GB 内存。
|
||
|
||
> [!insight] 类型选择是自动的
|
||
> SDS 在创建或扩容时，会根据字符串的实际长度**自动选择最小够用的 sdshdr 类型**。你不需要（也不能）手动指定。缩容时**不会自动降级**——和 intset、ziplist 的设计哲学一致，避免在阈值附近反复翻转。
|
||
|
||
### flags 字段的编码方式
|
||
|
||
`flags` 的低 3 位表示 sdshdr 类型（`SDS_TYPE_5/8/16/32/64`），高 5 位在 `sdshdr5` 中用于存储字符串长度。
|
||
|
||
```c
|
||
// 从 flags 中提取类型
|
||
#define SDS_TYPE_MASK 0x07 // 低 3 位：类型
|
||
#define SDS_TYPE_5 0
|
||
#define SDS_TYPE_8 1
|
||
#define SDS_TYPE_16 2
|
||
#define SDS_TYPE_32 3
|
||
#define SDS_TYPE_64 4
|
||
|
||
#define SDS_TYPE(t) ((t) & SDS_TYPE_MASK)
|
||
|
||
// 从 sdshdr5 的 flags 中提取长度
|
||
#define SDS_TYPE_5_LEN(f) ((f) >> 3) // 高 5 位
|
||
```
|
||
|
||
## 三、SDS 的两大核心优化
|
||
|
||
### 1. 空间预分配（Pre-allocation）
|
||
|
||
> [!question] 为什么每次扩容不刚好分配所需的大小？
|
||
> 如果字符串从 100 字节增长到 101 字节就要 `realloc`，那 10000 次增长就是 10000 次系统调用——每次都可能触发内存拷贝。空间预分配的思路是：**一次多分点，后面少 realloc**。
|
||
|
||
```go
|
||
// SDS 空间预分配策略（伪代码）
|
||
func (s *sds) growRequired(need int) {
|
||
if s.len + need <= s.alloc {
|
||
return // 剩余空间足够，直接返回
|
||
}
|
||
|
||
newLen := s.len + need
|
||
if newLen < SDS_MAX_PREALLOC { // SDS_MAX_PREALLOC = 1MB
|
||
s.alloc = newLen * 2 // 小于 1MB：翻倍
|
||
} else {
|
||
s.alloc = newLen + SDS_MAX_PREALLOC // 超过 1MB：多分 1MB
|
||
}
|
||
s.buf = realloc(s.buf, s.alloc + 1) // +1 是 '\0'
|
||
}
|
||
```
|
||
|
||
**策略总结**：
|
||
|
||
| 字符串增长后的长度 | 预分配大小 | 示例 |
|
||
|:---:|:---:|------|
|
||
| < 1MB | **翻倍**（newLen × 2） | 1KB → 2KB，下次追加直接用，无需 realloc |
|
||
| ≥ 1MB | newLen + 1MB | 10MB → 11MB，不会无限翻倍浪费内存 |
|
||
|
||
> [!insight] 为什么不用纯翻倍策略？
|
||
> 如果一个 500MB 的字符串翻倍就是 1GB——在 Redis 这种内存寸土寸金的场景，翻倍策略的浪费不可接受。所以超过 1MB 后只多加 1MB，这是一个**内存和性能的折中**。
|
||
|
||
> [!question] 追加操作是 SDS 最常见的"变长"操作。那缩短操作呢？
|
||
> 缩短操作（如 `SDS` 的 `sdssubstr` / `SET` 命令覆写值）会**惰性回收**多余空间——只修改 `len`，不立即 `realloc` 缩小。Redis 在字符串增长时预分配的"余量"这时会被利用起来，下次增长时就不需要再分配了。
|
||
>
|
||
> 但如果缩短幅度很大（`len < alloc / 10`），SDS 会主动释放多余空间，避免长期持有大量无用内存。
|
||
|
||
### 2. 惰性空间释放（Lazy Free）
|
||
|
||
SDS 缩短字符串时，不立即 `realloc` 释放多余空间，而是只更新 `len`：
|
||
|
||
```go
|
||
// 追加后又缩短——惰性释放的典型场景
|
||
s = sdsnew("hello") // len=5, alloc=5
|
||
s = sdscat(s, " world") // len=11, alloc=22（翻倍预分配）
|
||
sdstrim(s, " world") // len=5, alloc=22（空间还在，但没有"浪费"——下次追加可以直接用）
|
||
```
|
||
|
||
> [!tip] 这不是 Bug，是设计
|
||
> Redis 用这种策略避免了"缩了又扩"的系统调用风暴。如果后续还会写入新数据，这块预留空间立刻就能派上用场。
|
||
|
||
## 四、SDS 的 API 与二进制安全
|
||
|
||
### 二进制安全
|
||
|
||
> [!question] 什么叫"二进制安全"？
|
||
> C 字符串遇到 `\0` 就认为"字符串到此结束"。但如果你要存一张图片、一段 Protobuf 序列化数据、或者一个压缩后的 JSON——这些二进制数据里到处都是 `\0`。
|
||
>
|
||
> SDS 用 `len` 字段（而非 `\0`）判断字符串边界，所以**什么数据都能存**。这是 Redis 能存储任意二进制 key/value 的根本原因。
|
||
|
||
```c
|
||
// C 字符串：遇到 \0 截断
|
||
char buf[] = {'h', 'i', '\0', 'y', 'o', '\0'};
|
||
strlen(buf); // → 2 （丢了 "yo"）
|
||
|
||
// SDS：用 len 判断
|
||
sds s = sdsnewlen(buf, 6); // → 完整存入 6 个字节
|
||
sdslen(s); // → 6
|
||
```
|
||
|
||
### 常用 API
|
||
|
||
```c
|
||
// 创建
|
||
sds s1 = sdsnew("hello"); // 从 C 字符串创建
|
||
sds s2 = sdsnewlen(bin, bin_len); // 从二进制数据创建
|
||
|
||
// 拼接（自动扩容，二进制安全）
|
||
s1 = sdscat(s1, " world"); // 追加字符串
|
||
s1 = sdscatlen(s1, bin, bin_len); // 追加二进制数据
|
||
|
||
// 求长度（O(1)，不遍历）
|
||
size_t len = sdslen(s1);
|
||
|
||
// 释放
|
||
sdsfree(s1);
|
||
```
|
||
|
||
> [!tip] `sdslen()` 的实现
|
||
> 它只是一个简单的字段读取，不涉及遍历。对比 `strlen()` 的 O(N) 遍历，在 Redis 这种每秒百万次访问的场景下，这个优化的影响是**数量级的**。
|
||
|
||
```c
|
||
// sdslen 的实际实现（极其简洁）
|
||
static inline size_t sdslen(const sds s) {
|
||
unsigned char flags = s[-1]; // flags 在 buf 前面一个字节
|
||
switch (flags & SDS_TYPE_MASK) {
|
||
case SDS_TYPE_5: return SDS_TYPE_5_LEN(flags);
|
||
case SDS_TYPE_8: return SDS_HDR(8, s)->len;
|
||
case SDS_TYPE_16: return SDS_HDR(16, s)->len;
|
||
case SDS_TYPE_32: return SDS_HDR(32, s)->len;
|
||
case SDS_TYPE_64: return SDS_HDR(64, s)->len;
|
||
}
|
||
return 0;
|
||
}
|
||
```
|
||
|
||
> [!question] `s[-1]` 是什么魔法？
|
||
> SDS 的 `sds` 类型指向的是 `buf[]` 的起始位置（而不是 header 的起始位置）。所以 `s[-1]` 往回退一个字节就是 `flags` 字段。这种设计让 `sds` 指针可以直接作为普通 `char *` 传给任何 C 函数——**零拷贝兼容**。
|
||
|
||
### 更多 API
|
||
|
||
```c
|
||
// printf 风格格式化（避免先 snprintf 再 sdscat 的两次拷贝）
|
||
s = sdscatfmt(s, "age:%i name:%s", 25, "Tom");
|
||
|
||
// 修剪：移除指定字符集中的前后字符
|
||
sdstrim(s, " \t\n"); // 去除空白
|
||
|
||
// 子串（原地截取 buf[start..end]，更新 len）
|
||
sdsrange(s, 1, -2); // 只保留第 1 到倒数第 2 个字节（去掉首尾）
|
||
```
|
||
|
||
## 五、SDS 在 Redis 中的无处不在
|
||
|
||
> [!question] SDS 只用在 String 类型里吗？
|
||
> 不。SDS 是 Redis 的"通用字符串基础设施"，几乎所有需要存储字符串的地方都用它。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
SDS["SDS"] --> K["所有 Redis 键 (key)"]
|
||
SDS --> SV["String 类型的值 (value)"]
|
||
SDS --> HF["Hash / Set 的 field 名"]
|
||
SDS --> AB["AOF 缓冲区"]
|
||
SDS --> CB["客户端输入/输出缓冲区"]
|
||
SDS --> LOG["Redis 日志"]
|
||
|
||
classDef core fill:#e1f5fe,stroke:#2196f3
|
||
classDef data fill:#fff3e0,stroke:#ff9800
|
||
classDef infra fill:#e8f5e9,stroke:#4caf50
|
||
class SDS core
|
||
class K,SV,HF data
|
||
class AB,CB,LOG infra
|
||
```
|
||
|
||
### 内存占用的估算
|
||
|
||
一个 key 的内存开销 = `redisObject`(16B) + SDS header + 字符串数据。
|
||
|
||
以存储键 `"user:1001"`（10 字节）为例：
|
||
|
||
| 组成部分 | 类型 | 占用 |
|
||
|---------|------|:----:|
|
||
| `redisObject` | ptr 指向 SDS | 16B |
|
||
| SDS header | `sdshdr8`（10 字节 < 256） | 3B |
|
||
| 数据 + `\0` | "user:1001" | 11B |
|
||
| **合计** | | **~30B** |
|
||
|
||
> [!insight] 为什么小 key 的内存效率很重要？
|
||
> Redis 里可能有上亿个 key。如果每个 key 浪费 10 字节，一亿个 key 就浪费 ~1GB。SDS 的多级 header 设计就是在这种场景下尽可能压缩每一字节的开销。
|
||
|
||
> [!warning] 实际内存开销要算上 jemalloc 对齐
|
||
> Redis 使用 **jemalloc** 作为默认内存分配器，它会按 size class 对齐分配。上面理论值 30B，但 jemalloc 的最小分配粒度是 **8B**，小对象按 8/16/32/48/64B 对齐。所以这个 30B 的 SDS 实际会占用 **32B**（对齐到 32B 的 size class）。在用 `redis-cli --memory` 或 `MEMORY USAGE` 命令排查内存时要注意这点。
|
||
|
||
## 六、SDS 与 String 编码的关系
|
||
|
||
> [!question] SDS 就是 Redis String 类型的底层实现吗？
|
||
> 是，但不完全是。Redis String 类型有三种底层编码，SDS 只在其中两种中出现：
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
CMD["SET key value"] --> CHECK{"value 是什么?"}
|
||
CHECK -->|"能解析为 ≤ 20 位整数"| INT["OBJ_ENCODING_INT, 不使用 SDS"]
|
||
CHECK -->|"字符串 ≤ 44 字节"| EMB["OBJ_ENCODING_EMBSTR, SDS + redisObject 连续内存"]
|
||
CHECK -->|"字符串 > 44 字节"| RAW["OBJ_ENCODING_RAW, SDS + redisObject 分开分配"]
|
||
|
||
classDef intC fill:#e8f5e9,stroke:#4caf50
|
||
classDef embC fill:#e1f5fe,stroke:#2196f3
|
||
classDef rawC fill:#fff3e0,stroke:#ff9800
|
||
classDef checkC fill:#f3e5f5,stroke:#9c27b0
|
||
class INT intC
|
||
class EMB embC
|
||
class RAW rawC
|
||
class CHECK checkC
|
||
```
|
||
|
||
| 编码 | 条件 | 是否使用 SDS | 特点 |
|
||
|------|------|:----------:|------|
|
||
| `int` | 值能表示为 ≤ 20 位整数 | ❌ | 直接用 `redisObject` 的 `ptr` 字段存整数，零 SDS 开销 |
|
||
| `embstr` | 字符串 ≤ 44 字节（Redis ≥ 3.2） | ✅ | `redisObject` + SDS header + `buf` **一次 `malloc`** 连续分配，CPU cache 友好 |
|
||
| `raw` | 字符串 > 44 字节 | ✅ | `redisObject` 和 SDS **分开 `malloc`**，两次分配 |
|
||
|
||
> [!tip] embstr 的阈值变化
|
||
> Redis 3.2 之前 embstr 阈值是 **39 字节**（旧 SDS header 8B）。引入 sdshdr8 后 header 缩到 3B，多出 5B 空间给数据，所以阈值提升到 **44 字节**。embstr 是只读的——一旦你 `APPEND` 或修改 embstr 编码的值，Redis 会自动升级为 `raw` 编码。
|
||
|
||
> [!insight] SDS 在 active defragmentation 中的角色
|
||
> Redis 4.0+ 支持主动碎片整理（activedefrag）。当 jemalloc 报告某个内存页碎片率高时，Redis 会对 SDS 执行 `sdsdup` ——分配新 buffer → 拷贝数据 → 释放旧 buffer，把碎片化的内存"压实"。这是 SDS 在内存优化层面的又一个重要应用场景。
|
||
|
||
## 七、与 C 字符串的对比总结
|
||
|
||
| 维度 | C 字符串 (`char *`) | SDS |
|
||
|------|:------------------:|:---:|
|
||
| 求长度 | O(N) 遍历 | **O(1)** 读字段 |
|
||
| 二进制安全 | ❌ `\0` 截断 | ✅ 用 `len` 判断 |
|
||
| 缓冲区溢出 | ❌ API 不检查 | ✅ 自动扩容 |
|
||
| 内存分配 | 每次修改都可能 realloc | **预分配 + 惰性释放** |
|
||
| 兼容 C 函数 | ✅ 原生 | ✅ 末尾保留 `\0` |
|
||
| 内存开销 | 无 header | 3~17B header |
|
||
|
||
## 八、总结
|
||
|
||
> [!summary] SDS 的设计哲学
|
||
> SDS 是一个"看起来简单、细节极其讲究"的结构。它的核心思想是：
|
||
>
|
||
> 1. **用一点 header 空间换取所有常见操作的效率提升**——`len` 字段让长度查询从 O(N) 变 O(1)
|
||
> 2. **按需选型，极致省内存**——5 种 header 类型，最短仅 1 字节 header（sdshdr5），最长 17 字节
|
||
> 3. **预分配 + 惰性释放减少系统调用**——对 Redis 这种单线程模型，每次系统调用都可能引入延迟抖动
|
||
> 4. **兼容但不受限于 C**——保留 `\0` 能用 C 库，但核心逻辑不依赖它
|
||
>
|
||
> 理解 SDS，就理解了 Redis 处理字符串的底层逻辑——后面无论看 Hashtable 的 key、AOF 的缓冲区、还是客户端的输入，背后都是 SDS。
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/Redis/02-核心数据类型]] — 五种数据类型的编码切换全景
|
||
- [[hhs/Redis/02-核心数据类型/02-3-hashtable]] — dict 中 key 使用 SDS 存储
|
||
- [[hhs/Redis/02-核心数据类型/02-1-ziplist与listpack]] — 紧凑编码中的字符串存储
|
||
- [[hhs/Redis/04-RDB持久化]] — SDS 在序列化时的行为
|