467 lines
21 KiB
Markdown
467 lines
21 KiB
Markdown
---
|
||
tags: [Redis, 缓存, 架构, 线程模型, IO多路复用]
|
||
create time: 2026-05-26 10:33
|
||
---
|
||
|
||
# Redis 架构与线程模型
|
||
|
||
## 概述
|
||
|
||
Redis 是一个**基于内存的数据结构服务器**（data structure server），支持 String、Hash、List、Set、Sorted Set 等多种结构，并提供持久化、发布订阅、Lua 脚本、Stream 等高级能力。
|
||
|
||
本文聚焦于一个核心问题：**Redis 的内部架构长什么样？它是怎么做到单线程还这么快的？**
|
||
|
||
> [!question] 单线程 → 慢？这是直觉误区
|
||
> 提到"单线程"，大多数人的第一反应是"性能差"。但 Redis 单实例可达 **10 万+ QPS**，延迟在微秒级。为什么？因为对于常规 KV 操作，瓶颈通常不在 CPU，而在**网络 IO 和内存**。单线程执行命令反而省去了锁竞争和上下文切换的开销——这是 Redis 架构设计中最反直觉、也最关键的一个洞察。
|
||
|
||
## 整体架构
|
||
|
||
先从进程视角看 Redis 的内部模块组成：
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph Redis进程
|
||
direction TB
|
||
NET["网络层<br/>epoll/kqueue + IO多路复用"]
|
||
EVENT["事件循环<br/>单线程处理所有命令"]
|
||
ENGINE["存储引擎<br/>内存数据结构"]
|
||
BIO["后台线程池<br/>BIO lazyfree / AOF fsync"]
|
||
RDB_CHILD["子进程<br/>BGSAVE / AOF rewrite"]
|
||
end
|
||
|
||
CLIENT["客户端"] -->|"TCP 连接"| NET
|
||
NET --> EVENT
|
||
EVENT --> ENGINE
|
||
ENGINE --> BIO
|
||
ENGINE -->|"fork()"| RDB_CHILD
|
||
RDB_CHILD -->|"持久化文件落盘"| DISK["磁盘"]
|
||
|
||
style EVENT fill:#f9d,stroke:#96c
|
||
style ENGINE fill:#dfd,stroke:#6c6
|
||
style NET fill:#bbf,stroke:#66c
|
||
```
|
||
|
||
> [!tip] 一句话理解 Redis
|
||
> Redis = **单线程事件循环** + **IO 多路复用** + **纯内存操作**。这三个要素共同造就了它的高性能。
|
||
|
||
## 为什么单线程能这么快？
|
||
|
||
这是面试高频问题，但大多数回答只停留在"避免了锁"。让我们从根上拆解。
|
||
|
||
### 快的根本原因
|
||
|
||
| 因素 | 说明 |
|
||
|------|------|
|
||
| **纯内存操作** | 数据全部驻留在内存中，读写延迟 ~100ns 级，比磁盘快 10 万倍 |
|
||
| **单线程无锁** | 不存在线程安全问题，无需加锁/解锁，省去上下文切换开销 |
|
||
| **IO 多路复用** | 一个线程同时监听成千上万个连接（epoll），不会被某个慢连接阻塞 |
|
||
| **高效数据结构** | SDS、ziplist、quicklist、skiplist 等结构针对内存和性能做了极致优化 |
|
||
| **通信协议简单** | RESP（Redis Serialization Protocol）结构极简，解析无状态、无复杂序列化，开销远低于 JSON/XML 类协议 |
|
||
|
||
> [!question] 那为什么 MySQL 不用单线程？
|
||
> 因为瓶颈不同。MySQL 的查询可能涉及**磁盘 IO**（随机读写）、复杂 SQL 解析、事务锁管理——这些操作耗时从微秒到毫秒不等，单线程会被磁盘 IO 阻塞，无法处理其他请求。多线程能让一个线程等磁盘时，其他线程继续处理请求。
|
||
>
|
||
> Redis 也有 IO——网络 IO（与客户端之间的 socket 读写），但 IO 多路复用（epoll）已经用**单线程 + 事件驱动**高效地解决了这个问题。真正执行命令的环节是纯内存操作，耗时在亚微秒级，CPU 几乎不会空闲，所以单线程足矣。
|
||
>
|
||
> 简单记：**瓶颈在阻塞型 IO（如磁盘 IO）→ 多线程有意义，避免单线程被阻塞时无法响应其他请求；内存操作足够快、IO 已被事件驱动解决 → 单线程省去锁和上下文切换的开销，反而更高效。**（当然，Redis 6.0 仍对网络 IO 读写做了多线程优化，说明高并发下网络 IO 本身也会成为瓶颈——详见后文。）
|
||
|
||
### 单线程的局限
|
||
|
||
单线程也意味着 Redis 的单个实例**无法利用多核 CPU**。如果你的命令执行时间过长（如 `KEYS *`、大集合的 `SORT`），会阻塞后续所有请求——这就是为什么 Redis 社区反复强调**避免慢命令**。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
CMD1["正常命令<br/>SET key val<br/>1us"] --> QUEUE["命令队列"]
|
||
CMD2["正常命令<br/>GET key<br/>1us"] --> QUEUE
|
||
CMD3["慢命令<br/>KEYS *<br/>500ms"] --> QUEUE
|
||
QUEUE --> EXEC["单线程串行执行"]
|
||
|
||
CMD3 -.->|"阻塞后面所有命令"| BLOCK["后续请求全部等待 500ms"]
|
||
|
||
style CMD3 fill:#fdd,stroke:#c00
|
||
style BLOCK fill:#fdd,stroke:#c00
|
||
```
|
||
|
||
## 网络模型：IO 多路复用
|
||
|
||
Redis 单线程能同时处理上万连接的秘密在于 **IO 多路复用**（IO Multiplexing）。
|
||
|
||
### 传统阻塞 IO vs IO 多路复用
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant C1 as "客户端1"
|
||
participant C2 as "客户端2"
|
||
participant C3 as "客户端3"
|
||
participant S as "服务端线程"
|
||
|
||
Note over S: "传统阻塞IO 一个连接一个线程"
|
||
par 三个线程分别阻塞等待
|
||
C1->>S: "读请求"
|
||
S-->>C1: "阻塞等待数据..."
|
||
C2->>S: "读请求"
|
||
S-->>C2: "阻塞等待数据..."
|
||
C3->>S: "读请求"
|
||
S-->>C3: "阻塞等待数据..."
|
||
end
|
||
```
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant C1 as "客户端1"
|
||
participant C2 as "客户端2"
|
||
participant C3 as "客户端3"
|
||
participant EP as "epoll"
|
||
participant S as "单线程事件循环"
|
||
|
||
Note over S: "IO多路复用 一个线程监控所有连接"
|
||
C1->>EP: "注册监听"
|
||
C2->>EP: "注册监听"
|
||
C3->>EP: "注册监听"
|
||
EP->>S: "通知 C2 有数据可读"
|
||
S->>C2: "读取并处理"
|
||
EP->>S: "通知 C1 有数据可读"
|
||
S->>C1: "读取并处理"
|
||
```
|
||
|
||
> [!info] epoll 的核心思想
|
||
> epoll 是 Linux 内核提供的 IO 多路复用机制。简单来说：不是"一个线程傻等一个连接"，而是"一个线程同时盯住成千上万个连接，谁有数据来了就处理谁"。Redis 用 `ae_epoll.c` 封装了这套机制。
|
||
>
|
||
> 类比：你是一个餐厅服务员——传统模式是你站在 A 桌旁等他看完菜单（阻塞），而 IO 多路复用是你同时巡视所有桌，谁举手了就去服务（事件驱动）。
|
||
|
||
Redis 对不同平台做了适配：
|
||
|
||
| 平台 | 底层实现 | 说明 |
|
||
|------|---------|------|
|
||
| Linux | `epoll` | 最常用，性能最优 |
|
||
| macOS / BSD | `kqueue` | FreeBSD / macOS 原生机制 |
|
||
| Solaris | `evport` | Solaris 事件端口 |
|
||
| 其他 | `select` | 通用回退方案，连接数受限（FD_SETSIZE，默认 1024） |
|
||
|
||
### ae 事件库
|
||
|
||
Redis 自己实现了一个轻量级事件库（`ae.c`），将 IO 事件和定时事件统一抽象：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
AE["ae 事件库<br/>ae.c"] --> IOMULTI["IO 多路复用适配层"]
|
||
IOMULTI --> EP["epoll - Linux"]
|
||
IOMULTI --> KQ["kqueue - macOS BSD"]
|
||
IOMULTI --> EV["evport - Solaris"]
|
||
IOMULTI --> SEL["select - 通用回退"]
|
||
|
||
AE --> TIMER["定时事件<br/>serverCron 等"]
|
||
AE --> IO["文件事件<br/>客户端连接读写"]
|
||
|
||
style AE fill:#bbf,stroke:#66c
|
||
```
|
||
|
||
> [!tip] 事件循环的核心逻辑（伪代码）
|
||
> ```
|
||
> while (server.running) {
|
||
> // 1. beforeSleep 钩子：每轮循环开始前的"预处理"
|
||
> beforeSleep(); // 处理过期 key 惰性删除、AOF 缓冲刷新等
|
||
> // 2. aeProcessEvents 内部依次完成：
|
||
> // a. epoll_wait 阻塞等待（直到有 IO 事件或超时）
|
||
> // b. 遍历就绪事件，执行对应的命令读取/响应写出
|
||
> aeProcessEvents();
|
||
> // 3. 处理到期的定时事件（如 serverCron，每 100ms 一次）
|
||
> processTimeEvents();
|
||
> }
|
||
> ```
|
||
>
|
||
> 这就是 Redis 口中的「**主线程事件循环**」——一个永不停歇的 `while` 循环，依次处理 IO 事件和定时事件。
|
||
|
||
> [!info] beforeSleep——容易被忽略的关键钩子
|
||
> `beforeSleep()` 在每轮事件循环进入阻塞等待（`aeProcessEvents`）之前被调用，承担了多项"顺手"的清理工作：
|
||
>
|
||
> | beforeSleep 中的任务 | 说明 |
|
||
> |----------------------|------|
|
||
> | 过期 key 惰性删除 | 执行命令时发现 key 过期了，在这里统一回收 |
|
||
> | AOF 缓冲区刷新 | 如果 AOF 配置为 `everysec`，这里尝试将缓冲区写入内核 |
|
||
> | 处理被阻塞的客户端 | 有 key 变更时唤醒 `BLPOP` 等阻塞命令的客户端 |
|
||
> | 集群 failover 辅助 | Cluster 模式下处理故障转移相关的清理 |
|
||
>
|
||
> 简单说，`beforeSleep` 是事件循环"睡着前"的收尾动作，保证每轮循环结束后状态干净。
|
||
|
||
## RESP 通信协议
|
||
|
||
客户端与 Redis 之间的通信基于 **RESP**（Redis Serialization Protocol），这也是它高效的原因之一。
|
||
|
||
> [!question] 为什么不用 HTTP？
|
||
> HTTP 是为浏览器设计的文本协议，头部冗余大、解析复杂、无状态但需要反复握手。而 RESP 的设计目标是：**简单、无状态、可逐行流式解析**——正好匹配 Redis "命令 → 响应"的交互模型。
|
||
|
||
RESP2 是 Redis 自诞生以来一直使用的默认协议（Redis 6.0+ 仍默认使用 RESP2，客户端需通过 `HELLO` 命令主动升级到 RESP3）。RESP2 定义了 5 种数据类型：
|
||
|
||
| 前缀 | 类型 | 示例 | 说明 |
|
||
|------|------|------|------|
|
||
| `+` | 简单字符串 | `+OK\r\n` | 状态回复 |
|
||
| `-` | 错误 | `-ERR unknown command\r\n` | 错误回复 |
|
||
| `:` | 整数 | `:1000\r\n` | 整数回复（如 INCR 结果） |
|
||
| `$` | 批量字符串 | `$5\r\nhello\r\n` | 二进制安全，支持最大 512MB |
|
||
| `*` | 数组 | `*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n` | 命令和多元素结果均用此格式 |
|
||
|
||
一个 `SET name hello` 命令在 RESP2 中的编码：
|
||
|
||
```
|
||
*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$5\r\nhello\r\n
|
||
```
|
||
|
||
> [!info] RESP3（Redis 6.0+）
|
||
> RESP3 在 RESP2 基础上新增了 Map、Set、布尔、浮点数、Null 等原生类型，以及 Attribute、Push 消息等。客户端启用 `HELLO 3` 后可使用 RESP3，返回值语义更丰富（如 `HGETALL` 直接返回 Map 而非扁平数组）。但协议格式依然保持流式解析的特性。
|
||
|
||
## Redis 6.0+ 多线程 IO
|
||
|
||
> [!question] 既然单线程够用，为什么 Redis 6.0 又搞了多线程？
|
||
> 单线程事件循环处理命令确实很快，但**网络 IO 读写**（从 socket 读取请求、向 socket 写回响应）随着并发连接数增长，逐渐成为瓶颈。尤其是当响应数据量很大时（如 `LRANGE` 返回几千个元素），write 系统调用的耗时会显著拖慢事件循环。
|
||
|
||
Redis 6.0（2020 年发布）引入了 **IO 多线程**（Threaded IO），但请注意：
|
||
|
||
> [!warning] 关键区分：IO 多线程 ≠ 命令多线程
|
||
> Redis 6.0 的多线程**只用于网络 IO 的读写**，命令的**解析和执行仍然是单线程**。这保证了数据操作的线程安全性，无需加锁。
|
||
|
||
### IO 多线程工作流程
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant M as "主线程"
|
||
participant T1 as "IO线程1"
|
||
participant T2 as "IO线程2"
|
||
participant T3 as "IO线程3"
|
||
|
||
M->>M: "1 接受新连接,放入待处理队列"
|
||
M->>T1: "2 分配连接,让IO线程从socket读取请求"
|
||
M->>T2: "2 分配连接"
|
||
M->>T3: "2 分配连接"
|
||
Note over T1,T3: "并行从各自负责的连接中读取数据"
|
||
T1-->>M: "3 返回读取到的命令"
|
||
T2-->>M: "3 返回读取到的命令"
|
||
T3-->>M: "3 返回读取到的命令"
|
||
M->>M: "4 主线程串行执行所有命令"
|
||
M->>T1: "5 分配响应,让IO线程写回socket"
|
||
M->>T2: "5 分配响应"
|
||
M->>T3: "5 分配响应"
|
||
Note over T1,T3: "并行向各自负责的连接写回响应"
|
||
```
|
||
|
||
> [!tip] 一个形象的比喻
|
||
> 想象一个厨师（主线程）：
|
||
> - **6.0 之前**：厨师自己洗菜（读 IO）、自己炒菜（执行命令）、自己装盘（写 IO）
|
||
> - **6.0 之后**：雇了几个帮厨（IO 线程）帮忙洗菜和装盘，但炒菜（执行命令）还是厨师一个人
|
||
>
|
||
> 炒菜仍然是瓶颈，但洗菜装盘并行化后，整体吞吐量提升了。
|
||
|
||
### 开启方式（Redis 6.0+）
|
||
|
||
```conf
|
||
# redis.conf
|
||
io-threads 4 # IO 线程数（建议 CPU 核心数的一半，最少 2）
|
||
io-threads-do-reads yes # 是否对读操作也使用多线程（默认 no）
|
||
```
|
||
|
||
> [!warning] 版本要求
|
||
> `io-threads` 和 `io-threads-do-reads` 是 Redis 6.0 新增的配置项，6.0 之前的版本不支持，配置后会报错。
|
||
|
||
| 配置 | 说明 |
|
||
|------|------|
|
||
| `io-threads` | 线程数，包含主线程自身。设 4 表示 1 个主线程 + 3 个 IO 线程 |
|
||
| `io-threads-do-reads` | 默认只对**写响应**做多线程；设为 `yes` 后读请求也并行化 |
|
||
|
||
> [!question] 什么时候该开 IO 多线程？
|
||
> 以下条件**同时满足**时才值得开启：
|
||
> 1. 并发连接数很高（数千以上）
|
||
> 2. 单次响应数据量较大（大 Key 读取、大范围查询）
|
||
> 3. CPU 核心数充足（至少 4 核）
|
||
>
|
||
> 如果你的场景是大量小 Key 的 GET/SET（典型缓存场景），瓶颈在命令执行本身而非网络 IO，IO 多线程的收益可能并不明显。
|
||
|
||
## 后台线程：BIO
|
||
|
||
除了 IO 线程，Redis 还维护了一组 **BIO（Background IO）后台线程**，专门执行那些不适合在主线程中做的耗时操作，避免阻塞事件循环。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
MAIN["主线程事件循环"] -->|"提交任务"| QUEUE["BIO 任务队列"]
|
||
QUEUE --> T1["BIO 线程 1<br/>文件关闭"]
|
||
QUEUE --> T2["BIO 线程 2<br/>AOF fsync"]
|
||
QUEUE --> T3["BIO 线程 3<br/>lazyfree 异步删除"]
|
||
|
||
style MAIN fill:#f9d,stroke:#96c
|
||
style T1 fill:#bbf,stroke:#66c
|
||
style T2 fill:#bbf,stroke:#66c
|
||
style T3 fill:#bbf,stroke:#66c
|
||
```
|
||
|
||
BIO 线程池在 Redis 启动时就已创建（默认 3 个线程），各自负责不同类型的任务：
|
||
|
||
| BIO 线程 | 职责 | 触发场景 |
|
||
|----------|------|---------|
|
||
| `close` | 异步关闭文件描述符 | AOF 重写完成后关闭旧文件 |
|
||
| `fsync` | 异步刷盘 | `appendfsync everysec` 模式下每秒调用 |
|
||
| `lazyfree` | 异步释放大对象内存 | `UNLINK`、`FLUSHDB ASYNC`、过期 Key 惰性删除 |
|
||
|
||
> [!question] `DEL` 和 `UNLINK` 有什么区别？
|
||
> - `DEL`：在**主线程**中同步释放内存。如果 Key 是一个包含 100 万元素的 Hash，主线程会被阻塞几毫秒甚至更久
|
||
> - `UNLINK`：仅在主线程中断开 Key 的引用（O(1)），实际内存释放交给 BIO 的 `lazyfree` 线程异步完成——主线程几乎不受影响
|
||
>
|
||
> 生产环境中，删除大 Key **务必使用 `UNLINK`**（需 Redis 4.0+，4.0 以下版本只能用 `DEL`，此时应考虑分批删除或在从库执行）。
|
||
|
||
## 连接管理
|
||
|
||
每个客户端连接在 Redis 内部都对应一个 `redisClient` 结构体（存储连接状态、当前数据库、输入/输出缓冲区等），连接数直接影响内存占用和事件循环效率。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
C1["客户端1"] -->|"TCP"| EP["epoll 就绪队列"]
|
||
C2["客户端2"] -->|"TCP"| EP
|
||
CN["客户端N"] -->|"TCP"| EP
|
||
EP -->|"事件循环处理"| MAIN["主线程"]
|
||
|
||
style EP fill:#bbf,stroke:#66c
|
||
style MAIN fill:#f9d,stroke:#96c
|
||
```
|
||
|
||
### 关键配置
|
||
|
||
| 配置项 | 默认值 | 说明 |
|
||
|--------|--------|------|
|
||
| `maxclients` | 10000 | 最大同时连接数，超过后新连接被拒绝 |
|
||
| `tcp-backlog` | 511 | 内核 TCP 连接队列长度，需与系统 `somaxconn` 对齐 |
|
||
| `timeout` | 0（不超时） | 客户端空闲多久后断开，0 表示不主动断开 |
|
||
| `tcp-keepalive` | 300（Redis 3.2+） | TCP 心跳探测间隔（秒），及时发现死连接；3.2 之前默认为 0（不检测），易导致连接泄漏 |
|
||
|
||
> [!warning] 连接数暴涨的隐患
|
||
> 连接数过多不仅消耗内存（每个连接约占 ~1KB 结构体 + 输出缓冲区），更重要的是 **epoll 事件通知量增大**，每轮循环需要遍历更多就绪文件描述符，主线程在 IO 上的时间占比上升，直接影响命令处理吞吐量。
|
||
>
|
||
> 生产建议：在客户端使用**连接池**（如 go-redis 的 `PoolSize`），而非每次请求新建连接。
|
||
|
||
## 完整线程模型总览
|
||
|
||
把所有线程类型放在一起看：
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph Redis进程
|
||
direction TB
|
||
subgraph "单线程：事件循环"
|
||
EVENT["主线程<br/>命令解析 + 命令执行 + 定时任务"]
|
||
end
|
||
subgraph "IO 多线程 (Redis 6.0+)"
|
||
IOT1["IO 线程 1<br/>网络读写"]
|
||
IOT2["IO 线程 2<br/>网络读写"]
|
||
IOTN["IO 线程 N..."]
|
||
end
|
||
subgraph "BIO 后台线程"
|
||
BIO1["close 线程"]
|
||
BIO2["fsync 线程"]
|
||
BIO3["lazyfree 线程"]
|
||
end
|
||
subgraph "子进程 (fork)"
|
||
FORK["RDB BGSAVE<br/>AOF Rewrite"]
|
||
end
|
||
end
|
||
|
||
CLIENT["客户端"] --> IOT1
|
||
IOT1 -->|"读取命令"| EVENT
|
||
EVENT -->|"写响应"| IOT2
|
||
EVENT -->|"提交异步任务"| BIO1
|
||
EVENT -->|"触发持久化"| FORK
|
||
|
||
style EVENT fill:#f9d,stroke:#96c
|
||
style IOT1 fill:#bbf,stroke:#66c
|
||
style IOT2 fill:#bbf,stroke:#66c
|
||
style IOTN fill:#bbf,stroke:#66c
|
||
style BIO1 fill:#dfd,stroke:#6c6
|
||
style BIO2 fill:#dfd,stroke:#6c6
|
||
style BIO3 fill:#dfd,stroke:#6c6
|
||
style FORK fill:#ffd,stroke:#c90
|
||
```
|
||
|
||
> [!tip] 记忆口诀
|
||
> - **主线程**：命令执行的"唯一话事人"，保证了无锁设计
|
||
> - **IO 线程**：主线程的"快递员"，只负责搬数据不负责处理
|
||
> - **BIO 线程**：主线程的"后勤兵"，处理脏活累活（关文件、刷盘、删大 Key）
|
||
> - **子进程**：持久化的"外包队"，fork 出来做 RDB 快照和 AOF 重写
|
||
|
||
## serverCron 定时任务
|
||
|
||
主线程事件循环中，除了处理客户端命令，还会周期性执行 `serverCron`（默认每秒执行 `hz` 次，默认 `hz=10`，即每 100ms 一次）。这是 Redis 内部的"心跳"：
|
||
|
||
| 任务 | 频率 | 说明 |
|
||
|------|------|------|
|
||
| 过期 Key 扫描 | 每次 serverCron | 随机抽样检查，惰性删除已过期的 Key |
|
||
| 增量 rehash | 每次 serverCron | 对正在扩容的 Hash 表做渐进式迁移 |
|
||
| AOF 缓冲区刷新 | 每次 serverCron | 检查 aof_buf 是否需要写入/同步 |
|
||
| RDB / AOF 持久化检查 | 每次 serverCron | 检查是否满足 BGSAVE / BGREWRITEAOF 触发条件 |
|
||
| 集群心跳 | 每次 serverCron | Cluster 模式下发送 Gossip 消息 |
|
||
| 统计信息更新 | 每次 serverCron | 更新 INFO 中的 QPS、内存使用等指标 |
|
||
| 客户端超时断开 | 每次 serverCron | 检查 idle 超时的客户端连接 |
|
||
|
||
> [!question] 为什么 `hz` 不能调太高？
|
||
> `serverCron` 在**主线程**中执行，如果频率过高（如 `hz=1000`），定时任务本身会占用更多 CPU 时间片，反而影响命令处理吞吐量。官方建议保持默认 `hz=10`，除非你有明确的调优需求。
|
||
|
||
## fork 子进程与 COW 内存风险
|
||
|
||
Redis 的 RDB 持久化和 AOF 重写都依赖 `fork()` 创建子进程。`fork()` 本身是 O(1) 的（Linux 使用 Copy-On-Write），但**后续的内存增长可能非常危险**。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
P["父进程<br/>10GB 数据"] -->|"fork()"| C["子进程<br/>共享同一份物理页"]
|
||
C -->|"写入触发 COW"| NEW["复制物理页<br/>额外消耗内存"]
|
||
|
||
style P fill:#f9d,stroke:#96c
|
||
style C fill:#ffd,stroke:#c90
|
||
style NEW fill:#fdd,stroke:#c00
|
||
```
|
||
|
||
> [!warning] fork 后内存可能翻倍
|
||
> 子进程刚 fork 时与父进程共享物理内存页（COW）。但如果父进程在子进程做 RDB/AOF 期间**持续写入大量数据**，每次写操作都会触发 COW——被修改的内存页会被复制一份。
|
||
>
|
||
> 最坏情况：**fork 瞬间实际可用内存需要为当前数据量的 2 倍**。如果你的 Redis 实例用了 10GB，系统剩余内存不足 10GB，fork 后可能触发 OOM Killer，导致 Redis 进程被系统杀死。
|
||
>
|
||
> 生产建议：
|
||
> - 设置 `maxmemory`（如 `maxmemory 8gb`），并将其控制在物理内存的 **60%~70%**，为 fork COW 预留空间
|
||
> - 监控 `latest_fork_usec` 指标，超过 1ms 说明数据量大、fork 开销高
|
||
> - 写入密集时避免同时触发 RDB 和 AOF rewrite
|
||
|
||
## Redis 7.0+ 架构演进
|
||
|
||
Redis 7.0（2022 年发布）在持久化和线程模型方面带来了重要改进：
|
||
|
||
### Multi-Part AOF
|
||
|
||
Redis 7.0 重新设计了 AOF 机制，将单一 AOF 文件拆分为多个部分：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
BASE["base AOF<br/>RDB 格式全量快照"] -->|"append"| INCR["incr AOF<br/>增量命令日志"]
|
||
INCR -->|"rewrite 时合并"| NEW_BASE["新 base AOF"]
|
||
|
||
style BASE fill:#dfd,stroke:#6c6
|
||
style INCR fill:#bbf,stroke:#66c
|
||
```
|
||
|
||
| 特性 | 6.x 及之前 | 7.0+ |
|
||
|------|-----------|------|
|
||
| AOF 文件结构 | 单文件，rewrite 时写临时文件再 rename | base（RDB）+ incr（AOF 增量），独立管理 |
|
||
| rewrite 风险 | rewrite 期间出错可能损坏原 AOF | base 和 incr 分离，rewrite 失败不影响已有数据 |
|
||
| 加载速度 | 全量回放 AOF 命令 | 先加载 base（RDB 快），再回放 incr（少量日志） |
|
||
|
||
### IO 线程模型改进
|
||
|
||
Redis 7.0 对 IO 线程做了性能优化：
|
||
|
||
- **更精细的负载均衡**：主线程根据各连接的待处理数据量分配 IO 线程，避免某些线程"吃不饱"
|
||
- **减少锁竞争**：IO 线程与主线程之间的队列同步机制优化，降低临界区长度
|
||
|
||
> [!tip] 版本选择建议
|
||
> 如果是新项目，直接使用 **Redis 7.2+**（稳定版）。Multi-Part AOF 解决了老版 AOF rewrite 的数据安全问题，IO 线程优化也让高并发场景下的表现更稳定。
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/Redis/01-安装与部署]] — 安装与配置文件详解
|
||
- [[hhs/Redis/04-RDB持久化]] — fork 子进程做快照的具体过程
|
||
- [[hhs/Redis/05-AOF持久化]] — 主线程与 BIO fsync 线程的协作
|
||
- [[hhs/Redis/09-高级特性]] — 慢命令排查与 Lua 脚本的原子性
|
||
- [[hhs/Redis/11-运维与性能调优]] — `hz` 调优、慢查询日志、大 Key 治理
|