
# 一、什么是Redis持久化
Redis 默认数据放在**内存**，所以它的性能较高，一旦进程宕机、服务器断电，内存数据全部丢失。**持久化就是把内存里的数据写数据写入持久存储介质，例如固态硬盘（SSD）保存，重启 Redis 时可以从磁盘文件恢复数据。**
Redis 提供两种持久化方案：**RDB** 和 **AOF**，也可以两者同时开启即**混合持久化方式**
![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/9a5ec69b8fe349b1382ebf08cff84331.png)

# 二、为什么需要持久化
## 1. 重启 / 宕机后，从磁盘把数据装回来
内存断电清空，内存清零，磁盘文件可以长期保存。
- 机器断电、Redis 进程 crash、服务器重启
- 重启 Redis 时，自动加载 RDB/AOF 文件，把数据还原回内存
## 2. 做数据备份容灾
RDB 是某一刻的压缩快照，文件小、可以定时拷贝到其他服务器 / 云存储。盘坏了、误删了、机房没了，还能拿这份底稿把实例拉起来。万一服务器硬盘损坏、机房故障，可以拿 RDB 文件在新机器恢复数据。
## 3. 支撑迁移数据
想要把 Redis 实例迁移到另一台机器：导出 RDB 文件，在新节点加载，快速完成数据迁移
## 4.应对实例扩容、主从复制场景
主节点主库 `BGSAVE` 出 RDB 发给从节点，**主从初次全量同步，依赖 RDB**



# 三、Redis 持久化方式
Redis 持久化拥有以下三种方式
- **RDB**（Redis Database）：某一时刻把内存拍成一份二进制快照
- **AOF**（Append Only File）：把写命令追加成日志，重启时从头重放
- **混合**：文件头先是一张 RDB 近照，后面接增量 AOF
  
## 3.1 快照方式 RDB(Redis DataBase)
RDB（Redis DataBase）是将某一个时刻的内存快照（Snapshot），以二进制的方式写入磁盘的过程，每隔一段时间快照一次。RDB不记过程，只记结果。
### 3.1.1 RDB触发方式
#### 1.手动触发
- save 命令
  主线程遍历内存、写 `dump.rdb`，这段时间 **不处理任何客户端命令**。实例越大，卡得越久。生产不要用；只适合停写维护、或确定几乎没流量的时候。

```bash
admin:redis/ $ ls -l dump.rdb                                                                                                                   [11:03:45]
-rw-r--r--  1 admin  staff  562827  9 11 11:02 dump.rdb
```
``` bash
127.0.0.1:6379> save
OK
```
``` bash
admin:redis/ $ ls -l dump.rdb                                                                                                                   [11:05:56]
-rw-r--r--  1 admin  staff  562827  9 11 11:05 dump.rdb
```

  当执行完 `save` 命令之后，持久化文件 `dump.rdb` 的修改时间就变了，这就表示 `save` 成功的触发了 RDB 持久化
- bgsave命令
  - 后台保存，会fork一个子线程，整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了。
  - 主进程 `fork()` 出一个 **子进程**（不是子线程）。`fork` 本身会短暂堵住主线程——子进程创建完成之后，Redis 的主进程就可以响应其他客户端的请求。
  - 已经有一次 `BGSAVE`（或 AOF rewrite）在跑时，再发 `BGSAVE` 会被拒绝，不会叠两个子进程一起拍。查进度用 `LASTSAVE` 或 `INFO persistence` 里的 `rdb_bgsave_in_progress` / `rdb_last_bgsave_status`

```bash
SAVE      # 主线程拍，期间不处理命令，生产别用
BGSAVE    # fork 子进程拍，只在 fork 时短暂堵住
LASTSAVE  # 上一次成功拍照的 Unix 时间戳
```  
#### 2.自动触发
-  save m n
`save m n` 是指在 m 秒内，如果有 n 个键发生改变，则自动触发持久化。 参数 m 和 n 可以在 Redis 的配置文件中找到，例如，`save 60 1` 则表明在 60 秒内，至少有一个键发生改变，就会触发 RDB 持久化。 自动触发持久化，本质是 Redis 通过判断，如果满足设置的触发条件，自动执行一次 `bgsave` 命令。 注意：当设置多个 save m n 命令时，满足任意一个条件都会触发持久化
`save m n` 命令可以同时配置多条
```bash
# RDB 保存的条件
save 900 1 
save 300 10 
save 60 10000
```
-  flushall
`flushall` 命令用于清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 `flushall` 命令之后，则会触发自动持久化，把 RDB 文件清空
-  主从同步触发
在 Redis 主从复制中，当从节点执行全量复制操作时，主节点会执行 `bgsave` 命令，并将 RDB 文件发送给从节点，该过程会自动触发 Redis 持久化
-  停机保存
  `SHUTDOWN` 默认会在退出前再 `SAVE` 一次（`SHUTDOWN NOSAVE` 才跳过），免得正常停机还丢掉最后一段写入。这是停机动作，不是运行中的自动规则。

### 3.1.2 RDB优缺点
#### RDB优点
- **体积小**：RDB 数据非常紧凑的单文件时间点镜像，文件是压缩过的二进制，体积小，拷走做备份、容灾、搬迁都方便。例如，你可以每小时归档过去 24 小时的 RDB 文件，同时每日保存一份快照，保留 30 天。发生故障时，可以轻松恢复数据集的各个历史版本
- **适用于容灾恢复**，它是一个紧凑独立的文件，可以更快的传输到远端数据中心，或者上传到 Amazon S3（可加密存储）进行 Redis 服务恢复
- **性能高**：父进程做持久化时仅需要 `fork()` 出子进程，后续全部持久化工作都交给子进程完成；父进程本身不会执行磁盘 IO 等耗时操作。
- **重启快**：面对大数据集场景，RDB 的重启加载速度要快于 AOF。
- 在从节点上，RDB 支持**故障切换、实例重启后的部分重同步**
#### RDB缺点
- 如果希望尽可能降低 Redis 异常停止（例如断电）带来的数据丢失风险，RDB 并不合适。
因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，通常快照至少间隔 5 分钟才会生成一次；一旦 Redis 非正常宕机，就可能丢失最近几分钟的数据。
- RDB 需要频繁调用 `fork()` 创建子进程来完成磁盘持久化。当数据集很大时，`fork()` 会比较耗时；如果数据集极大且 CPU 性能较差，会造成 Redis 短暂阻塞，停止对外服务，阻塞时长从几毫秒到 1 秒不等。AOF 同样会执行`fork()`，但调用频率更低，你可以调整 AOF 重写的触发频率，而且不会牺牲数据可靠性
  
### 3.1.3 RDB配置查询与设置
1. 命令格式 config get xxx ，
如，想要获取 RDB 文件的存储名称设置，可以使用 `config get dbfilename`
```bash
127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"
```
2. 查询 RDB 的文件目录，可使用命令 `config get dir`
```bash
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis"
```
3. 设置 RDB 的配置，可以通过以下两种方式：
- 手动修改 Redis 配置文件；
- 使用命令行设置，例如，使用 `config set dir "/usr/data"` 就是用于修改 RDB 的存储目录

### 3.1.4 RDB 文件恢复
当 Redis 服务器启动时，如果 Redis 根目录存在 RDB 文件 dump.rdb，Redis 就会自动加载 RDB 文件恢复持久化数据。 如果根目录没有 dump.rdb 文件，请先将 dump.rdb 文件移动到 Redis 的根目录。 **验证 RDB 文件是否被加载** Redis 在启动时有日志信息，会显示是否加载了 RDB 文件，我们执行 Redis 启动命令：`src/redis-server redis.conf`


## 3.2 文件追加方式AOF(Append Only File)
AOF 记录的是Redis收到的每一条命令，不是某一刻的内存切片。写请求先改内存，再把这条写命令追加到日志里；重启时从文件头重放，把内存重新堆出来。所以它比 RDB 更新，文件也更大，恢复也更慢AOF 可以把 Redis 每个键值对操作都记录到文件（appendonly.aof）中。

### 3.2.1 持久化查询和设置
#### 1.查询AOF启动状态
使用 `config get appendonly` 命令，第一行为 AOF 文件的名称，而最后一行表示 AOF 启动的状态，yes 表示已启动，no 表示未启动
```bash
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
```
#### 2. 开启 AOF 
Redis 默认是关闭 AOF 持久化的，想要开启 AOF 持久化，有以下两种方式：
- **通过命令行开启**；
   `config set appendonly yes` 命令
    - 优点：无需重启 Redis 服务
    - 缺点：如果 Redis 服务重启，则之前使用命令行设置的配置就会失效
- **通过修改配置文件开启**。
配置文件中设置 `appendonly yes` ，默认 `appendonly no` 表示关闭 AOF 持久化。（Redis 的配置文件在它的根路径下的 redis.conf 文件中获取 Redis 的根目录可以使用命令 `config get dir` ）
  - 优点：无论重启多少次 Redis 服务，配置文件中设置的配置信息都不会失效
  - 缺点：每次修改配置文件都要重启 Redis 服务才能生效
  
### 3.2.2 AOF触发方式

#### 1.自动触发
有两种情况可以自动触发 AOF 持久化，分为是：**满足 AOF 设置的策略触发**和**满足 AOF 重写触发。**其中，AOF 重写触发会在本文的后半部分详细介绍，这里重点来说 AOF 持久化策略都有哪些。 AOF 持久化策略，分为以下三种：
| 策略 | 何时把日志刷到盘上 | 宕机大约丢多少 | 代价 |
| --- | --- | --- | --- |
| `always` | 每条写命令都在主线程 `fsync` | 几乎不丢（最多当前这一条） | 延迟高，写入 QPS 掉一截 |
| `everysec`（默认） | 后台大概每秒写入一次磁盘 | 最多丢失一秒的数据 | 生产最常见的折中 |
| `no` | 不设置写入磁盘的规则，交给操作系统 | 根据当前操作系统来决定何时写入磁盘，可能几十秒，Linux 默认 30s 写入一次数据至磁盘 | 最快，窗口不受你控 |

#### 2.手动触发
客户端执行 `bgrewriteaof` 命令就可以手动触发 AOF 持久化
```bash
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
```
### 3.2.3 日志文件太大了怎么办？——AOF重写
#### 1.什么是AOF重写？
AOF 重写（AOF Rewrite）是 Redis 的后台机制，随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写期间原有 AOF 文件继续正常追加，保证服务不中断。重写完成后，Redis 切换到新 AOF 文件，替换旧文件。
#### 2.为什么要AOF重写？
-  AOF 是**追加写**，会膨胀。
  - 同一 key 被改很多次。 计数器加一万次，日志一万行，内存里就一个整数。不重写，磁盘和重启重放都在为过程买单。
  - 删掉的数据还躺在旧日志里。 `SET` 再 `DEL`，旧账两条都在，重放时先建再拆，纯浪费。
-  减少 AOF 文件体积，加快 Redis 宕机后恢复数据的速度
  - 重启时间跟文件体积走。从不重写，AOF 涨到几十 GB，冷启动重放十几分钟。
-  避免磁盘持续被巨大日志占用
#### 3. AOF重写触发
**1) 手动触发**
命令：`BGREWRITEAOF`
执行后，Redis 尝试立刻启动 AOF 后台重写 （注意BGSAVE / BGREWRITEAOF 同一时刻只能执行一个子后台进程）
**2) 自动触发**
触发 AOF 文件重写，要满足两个条件，这两个条件也是配置在 Redis 配置文件中的，它们分别：
- auto-aof-rewrite-min-size：允许 AOF 重写的最小文件容量，默认是 64mb 。
- auto-aof-rewrite-percentage：AOF 文件重写的大小比例，默认值是 100，表示 100%，也就是只有当前 AOF 文件，比最后一次（上次）的 AOF 文件大一倍时，才会启动 AOF 文件重写。
两个**自动重写触发条件必须同时满足**，才会自动执行 BGREWRITEAOF；手动`BGREWRITEAOF`不受这两个参数限制
#### 4. AOF重写流程
- 主进程 `fork` 出 bgrewriteaof子进程。`fork` 那一下会短暂堵住主线程；之后主进程继续接客户端。
- **子进程** 子进程遍历ork 那一瞬的内存数据库内所有 key，根据 key 类型生成最简命令，写入临时AOF文件。过期已删的、过程中的中间态，都不会写进去。
- **主进程** 正常处理客户端写请求。新来的写命令两头都记：
    - 旧 AOF 继续追加（万一重写失败，旧账还在）
    - 同时攒到一块「重写缓冲区」里，等会儿补给新文件。
- 子进程写完，通知主进程，新 AOF 临时文件已经生成。
- 主进程短暂阻塞，把重写缓冲区里积下的增量补到新文件末尾，`fsync`，再 **原子改名** 换成正在用的 AOF，旧文件删掉。
- 重制基准值，记下新的 `aof_base_size`，作为下一次自动重写的比较基数。

```
BGREWRITEAOF / 体积够了
        │
        ├─ fork 子进程 ──► 按当前内存写临时新账（可带 RDB 头）
        │
        └─ 父进程继续服务
                ├─ 旧 AOF 照常追加
                └─ 增量先攒着
                        │
                        └─ 子进程结束 ──► 补增量 ──► fsync ──► 改名换上新AOF文件
```
![image](https://developer.qcloudimg.com/http-save/yehe-9980940/463c48ac9f422d6d5dc4cfcdfa07a8ba.webp)
### 3.2.3 AOF优缺点
#### AOF优点
- **持久化可靠性更高** 支持多种刷盘策略：不刷盘、每秒刷盘、每条命令执行后刷盘。默认策略为**每秒刷盘**，写入性能依旧优秀。刷盘操作由后台线程执行；主线程会尽可能在没有刷盘任务时处理写入，即使发生了意外情况，最多只会**1 秒内的数据**；
- AOF 日志是追加写（append-only）日志，不存在磁盘寻道开销；断电时也不容易出现文件损坏。即便由于磁盘满等原因，日志末尾存在半截命令，`redis-check-aof` 工具也能轻松修复；
- 当 AOF 文件体积过大时，Redis 可以在后台自动重写 AOF。整个重写过程安全可靠：Redis 持续往旧文件追加命令，同时生成一份全新文件，里面只包含重建当前数据集所需的最少操作；新文件就绪后，Redis 切换文件，后续写入追加到新文件
- AOF 持久化文件，非常容易理解和解析，它是把所有 Redis 键值操作命令，以文件的方式存入了磁盘。即使不小心使用 `flushall` 命令删除了所有键值信息，只要使用 AOF 文件，删除最后的 `flushall` 命令，重启 Redis 即可恢复之前误删的数据。
#### AOF缺点
- 对于相同的数据集来说，AOF 文件要大于 RDB 文件；
- 在 Redis 负载比较高的情况下，RDB 比 AOF 性能更好；
- RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 更健壮。
## 3.3 混合持久化(RDB+AOF)
核心：**AOF 文件头部存放 RDB 格式快照，RDB 之后追加增量 AOF 命令**。
重启加载逻辑：先加载头部 RDB 快照，再回放后面 AOF 增量命令
### 3.3.1 为什么要选择混合持久化
单独用 RDB：重启加载快，但丢失数据多（快照间隔内数据全丢）。
单独纯 AOF：丢失数据少，但 AOF 文件巨大，重启回放海量命令，影响 Redis 的启动速度，加载慢。
混合持久化兼顾两者优势：

1. **加载速度接近 RDB**：头部是二进制 RDB 快照，不用逐条回放大量写命令；
2. **数据安全性接近 AOF**：RDB 快照之后的增量变更用 AOF 日志保存，最多丢失 1 秒数据（默认`appendfsync everysec`）；
3. AOF 重写生成新文件时，直接生成「RDB 头部 + 增量 AOF」，压缩 AOF 文件体积。
### 3.3.2 怎么开启混合持久化
#### 1. 命令行开启
使用命令 `config set aof-use-rdb-preamble yes`，重启 Redis 服务之后，设置的配置就会失效
```bash
`config set aof-use-rdb-preamble yes`
```
#### 2. Redis配置文件开启
在 Redis 的根路径下找到 redis.conf 文件，把配置文件中的 `aof-use-rdb-preamble no` 改为 `aof-use-rdb-preamble yes`
```请在此输入代码块语言
appendonly yes
aof-use-rdb-preamble yes   # 开启混合持久化，Redis 5/6/7 默认yes
```



Redis 默认数据放在内存，所以它的性能较高，一旦进程宕机、服务器断电，内存数据全部丢失。持久化就是把内存里的数据写数据写入持久存储介质，例如固态硬盘（SSD）保存，重启 Redis 时可以从磁盘文件恢复数据。Redis 提供两种持久化方案：RDB 和 AOF，也可以两者同时开启即混合持久化方式

Redis 持久化——Redis系列(九)

后端

Redis持久化方案详解：RDB快照、AOF日志及混合模式对比。涵盖触发机制、配置优化、数据恢复策略与性能权衡，帮助开发者根据业务场景选择最合适的持久化方案，确保数据安全与高可用性。

日志文件

数据中心

代码解释

数据备份

数据迁移

数据丢失

数据安全

大数据

云存储

服务器

数据库

容灾

Redis

Linux

Unix

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis 持久化——Redis系列(九)-腾讯云开发者社区-腾讯云

Redis 持久化——Redis系列(九)

Redis 持久化——Redis系列(九)

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐