Redis持久化机制

概述

Redis是基于内存的nosql数据库，数据一般是存储于内存中，想让内存数据保存到磁盘中，我们需要利用Redis的持久化机制。

Redis的持久化机制用于将内存中的数据保存到磁盘，以便在重启后恢复数据。

Redis 提供了两种主要的持久化方式：

RDB（Redis Database）快照
AOF（Append Only File）日志

在Redis4.0版本之后，引入了混合持久化（RDB + AOF）

RDB持久化方式讲解

RDB 持久化机制以轻量、快速为核心优势，适合对数据实时性要求不高但需要高效恢复的场景。在生产环境中，通常与 AOF 结合使用（混合持久化），以平衡数据安全性和性能。合理配置触发策略、监控文件生成状态，并做好备份管理，是确保 RDB 机制稳定运行的关键。

其使用场景通常为：

缓存场景：允许部分数据丢失（如缓存热点数据），优先使用 RDB 提升恢复速度。
定期全量备份：例如每天生成一次 RDB 文件，用于历史数据存档或容灾切换。
主从复制：Redis 主从集群中，主节点通过 RDB 向从节点同步初始数据（增量同步通过 AOF 实现）。

RDB实现原理

RDB 是 Redis 在某个时间点将数据写入一个临时文件（快照），持久化结束后，用这个临时文件替换之前的持久化文件，达到数据持久化的目的。

RDB触发持久化方式

手动触发

SAVE 命令：阻塞主线程，直到 RDB 文件生成完毕，期间无法处理客户端请求。

BGSAVE 命令： fork 出一个子进程来生成 RDB 文件，主线程继续处理请求，不阻塞。

自动触发

通过配置文件（redis.conf）中的 save 配置项，满足条件时自动执行 BGSAVE。

复制代码

# 基础配置项
save 900 1        # 900秒内至少有1个键被修改，触发快照
save 300 10       # 300秒内至少有10个键被修改，触发快照
save 60 10000     # 60秒内至少有10000个键被修改，触发快照

# RDB 文件存储路径（建议使用独立磁盘，避免与系统盘混用）
dir /data/redis/rdb
# RDB 文件名（可包含日期戳，便于区分版本）
dbfilename "dump-${DATE}.rdb"  # 需配合脚本动态生成，Redis 不支持变量直接替换
# 压缩配置（生产环境建议保持默认）
rdbcompression yes
# 校验配置（加载时校验 RDB 文件完整性，默认开启）
rdbchecksum yes

RDB文件管理

文件存储位置与命名

存储路径：由配置项 dir 决定，默认值为 /var/lib/redis（可通过 config get dir 查看）。
文件名：由配置项 dbfilename 决定，默认值为 dump.rdb（可通过 config get dbfilename 查看）。

压缩配置：

RDB 文件默认使用 LZF 算法压缩，可通过配置项 rdbcompression yes|no 开启或关闭（默认 yes）。
关闭压缩可提升生成速度，但会增加文件体积，适用于 CPU 资源紧张的场景。
二进制格式：RDB 文件为二进制格式，不可直接读取，但体积小、恢复速度快。

RDB恢复方式及时机

当Redis宕机重启之后会自动加载rdb文件（如果同时开启了AOF，则优先加载AOF）。
如果想强制加载RDB，忽略AOF时，可在配置中设置 appendonly no，或在启动时指定 --loadrdb 参数。
手动加载指定加载RDB文件

--dbfilename：指定dump.rdb文件的路径

redis-server --dbfilename /path/dump.rdb

RDB实战

复制代码

# 创建模拟数据
127.0.0.1:6379> set test1 1
OK
127.0.0.1:6379> set test2 2
OK
127.0.0.1:6379> set test3 3
OK
127.0.0.1:6379> keys *
1) "test1"
2) "test2"
3) "test3"

# 执行快照
127.0.0.1:6379> bgsave
Background saving started

[root@master /data00/data/redis]# ll
total 96
-rw-r--r-- 1 root root   125 May 29 19:28 dump.rdb

模拟一下将dump.rdb文件删除，重启之后数据还在吗？

复制代码

[root@master /data00/data/redis]# mv dump.rdb ~
# 强制停止redis
[root@master ~]# ps -ef | grep redis
root      908803  635754  0 19:38 pts/0    00:00:00 grep redis
root     1818909       1  0 May20 ?        00:19:44 redis-server 0.0.0.0:6379
[root@master ~]# pkill redis-server

启动Redis服务

复制代码

[root@master ~]# redis-server /data00/data/redis/redis.conf
[root@master ~]# ss -lntup | grep 6379
tcp   LISTEN 0      511                           0.0.0.0:6379       0.0.0.0:*    users:(("redis-server",pid=1807376,fd=6))

检查数据是否存在

复制代码

127.0.0.1:6379> keys *
(empty array)

模拟恢复dump.rdb文件

复制代码

# 将dump.rdb文件迁移到Redis数据目录下
[root@master /data00/data/redis]# mv ~/dump.rdb /data00/data/redis

# 检查rdb文件是否损坏
[root@master /data00/data/redis]# redis-check-rdb dump.rdb
[offset 0] Checking RDB file dump.rdb
[offset 27] AUX FIELD redis-ver = '6.2.18'
[offset 41] AUX FIELD redis-bits = '64'
[offset 53] AUX FIELD ctime = '1748518107'
[offset 68] AUX FIELD used-mem = '875088'
[offset 84] AUX FIELD aof-preamble = '0'
[offset 86] Selecting DB ID 0
[offset 125] Checksum OK
[offset 125] \o/ RDB looks OK! \o/
[info] 3 keys read
[info] 0 expires
[info] 0 already expired

# 启动Redis并检查数据
[root@master ~]# redis-server /data00/data/redis/redis.conf
[root@master ~]# redis-cli 
127.0.0.1:6379> auth !Xinxin123
OK
127.0.0.1:6379> keys *
1) "test2"
2) "test1"
3) "test3"

AOF持久化方式讲解

AOF（Append Only File）是 Redis 提供的一种实时性更强的持久化方式，通过记录所有写操作命令（而非数据本身）来保证数据的完整性。

核心原理

客户端发送写命令（如 SET key value）。
Redis 执行命令并将结果返回客户端。
将命令写入 AOF 缓冲区（内存）。
根据配置策略将缓冲区内容同步到磁盘。

刷盘策略（appendfsync）

always：每个写命令都同步到磁盘，最多会丢失一个命令
everysec：每秒同步一次磁盘（默认配置），最多丢失 1 秒数据
no：由操作系统决定何时刷盘（通常为 30 秒左右，取决于内核调度），可能会丢失大量数据

AOF相关配置

复制代码

# 启用 AOF（默认关闭）
appendonly yes

# 刷盘策略（推荐 everysec，兼顾安全与性能）
appendfsync everysec

# AOF 文件名（默认 appendonly.aof）
appendfilename "appendonly.aof"

# AOF 文件存储目录（与 RDB 共享，由 dir 参数决定）
dir /var/lib/redis

# 开启混合持久化（Redis 4.0+ 支持）
aof-use-rdb-preamble yes

AOF重写机制

为什么需要重写？

随着写命令不断追加，AOF 文件会越来越大，可能导致：

文件体积膨胀：占用大量磁盘空间。
恢复速度变慢：重启时需要重放更多命令。

重写原理

通过 BGREWRITEAOF 命令触发，Redis 会：

fork 子进程遍历当前内存数据。
生成最简命令集（如合并多个 SET 为一个）。
替换原有 AOF 文件，保证原子性。

自动触发重写

在 redis.conf 中配置：

复制代码

# 当 AOF 文件比上次重写后增长超过 100% 时触发
auto-aof-rewrite-percentage 100

# AOF 文件至少达到 64MB 才触发重写（避免频繁重写小文件）
auto-aof-rewrite-min-size 64mb

AOF恢复机制

Redis 自动加载 AOF 日志

Redis 服务器启动时会优先尝试加载 AOF 文件来恢复数据，前提是满足以下条件：

1、配置文件中需启用 AOF 持久化，在 Redis 的配置文件（redis.conf）中，appendonly 参数需设置为 yes：

复制代码

appendonly yes

2、存在有效的 AOF 文件，Redis 会检查 appendfilename 参数指定的 AOF 文件名（默认是 appendonly.aof）是否存在，且文件内容未损坏

混合持久化机制讲解

Redis的混合持久化机制（Hybrid Persistence）是Redis4.0版本及以上的新特性，混合持久化机制（Hybrid Persistence）是结合了 AOF（Append Only File）和 RDB（Redis Database）两种持久化方式优点的策略，旨在提供更高效的数据恢复能力和更细粒度的数据安全性。

工作原理

混合持久化机制的核心是：

在执行 AOF 重写（BGREWRITEAOF）时，将当前内存中的数据以 RDB 快照格式写入 AOF 文件，后续的写命令继续以 AOF 格式追加到文件末尾。

具体流程如下：

启用混合持久化：在 redis.conf 中配置 aof-use-rdb-preamble yes（默认关闭）。
AOF 重写触发：当 AOF 文件达到一定大小或手动执行 BGREWRITEAOF 时，Redis 会：
- 生成 RDB 快照数据（二进制格式，紧凑高效）。
- 将 RDB 数据写入新 AOF 文件的开头。
- 继续将后续的写命令以文本协议格式追加到 AOF 文件末尾。
数据恢复：Redis 启动时，先加载 RDB 部分（快速恢复大部分数据），再执行 AOF 追加部分的命令（恢复最新操作）。

混合持久化相关配置

复制代码

appendonly yes                # 启用 AOF 持久化
aof-use-rdb-preamble yes      # 启用混合持久化（Redis 4.0+ 支持）

# 触发AOF重写
auto-aof-rewrite-percentage 100  # AOF 文件大小比上次重写后增长 100% 时触发
auto-aof-rewrite-min-size 64mb   # AOF 文件最小达到 64MB 时触发

数据恢复流程

当 Redis 服务器重启时，加载混合 AOF 文件的流程：

检查文件格式：识别 AOF 文件是否包含 RDB 前缀。
加载 RDB 部分：快速解析二进制 RDB 数据，重建内存状态。
执行 AOF 部分：继续执行 RDB 之后的 AOF 命令，恢复最新操作。

混合持久化 vs 纯 AOF vs 纯 RDB区别

特性	混合持久化	纯 AOF	纯 RDB
数据恢复速度	快（RDB 加载 + 少量 AOF 命令）	较慢（逐行执行命令）	最快（直接加载快照）
文件体积	小（RDB 二进制 + 增量 AOF）	大（纯文本命令）	中等（二进制快照）
数据安全性	高（接近 AOF，仅丢失未同步数据）	高（取决于 fsync 策略）	低（可能丢失最后一次快照后的数据）
写操作开销	中等（重写时生成 RDB）	高（频繁 fsync）	低（定期快照）
兼容性	Redis 4.0+	全版本支持	全版本支持

Redis持久化机制

概述

RDB持久化方式讲解

RDB实现原理

RDB触发持久化方式

手动触发

自动触发

RDB文件管理

文件存储位置与命名

压缩配置：

RDB恢复方式及时机

--dbfilename：指定dump.rdb文件的路径

RDB实战

模拟一下将dump.rdb文件删除，重启之后数据还在吗？

模拟恢复dump.rdb文件

AOF持久化方式讲解

核心原理

刷盘策略（appendfsync）

AOF相关配置

AOF重写机制

为什么需要重写？

重写原理

自动触发重写

AOF恢复机制

Redis 自动加载 AOF 日志

混合持久化机制讲解

工作原理

混合持久化相关配置

数据恢复流程

混合持久化 vs 纯 AOF vs 纯 RDB区别