1.Redis四种持久化策略

在前两篇文档中，我们学习了RDB、AOF的相关知识，它们各有优缺点。在实际应用中，需要根据场景选择适合的持久化策略。

Redis 支持以下四种方式：

• 无持久化：同时关闭RDB、AOF
• RDB：只开启RDB
• AOF：只开启AOF
• 混合模式：同时支持RDB、AOF

2. 案例演示

2.1 无持久化

适用于以下场景：

• 缓存层 ：作为数据库查询缓存时，如果数据丢失，可以重新获取并填充到缓存中，持久化不是必需的。
• 实时分析 ：在实时数据流处理或分析中，Redis 可能被用作一个中间存储层，用于聚合、过滤或转换数据。由于这些数据通常是实时生成的，并且只在一段时间内需要，因此可能不需要持久化。一旦分析完成或数据过期，它们就可以被丢弃。
• 临时存储 ：在某些应用中，Redis 可能被用作临时存储来存储会话数据、临时令牌或其他短生命周期的信息。由于这些数据本质上是临时的，并且在一段时间后会被丢弃或失效，因此可能不需要持久化。

在redis.conf中同时关闭RDB、AOF：

save ""
appendonly no

注意，关闭后是依然可以使用save、bgsave、bgrewriteaof命令生成文件。默认启用RDB，所以在安装目录可以看到 dump.rdb 文件：

将 dump.rdb 文件删除，然后启动 Redis ，虽然之前存入了数据，但是因为没有恢复文件，所以数据库是空：

重新存入数据后，由于禁用了 RDB ，所以不会生成dump.rdb 文件，一旦重新启，所有数据将会丢失。

2.2 RDB

Redis 默认启用RDB持久化，只生成单个二进制文件，比AOF性能更好，但是可能会存在数据丢失问题。Redis本身是十分稳定的，适用于对数据一致性要求不是特别高的场景：

• 主从复制 ：Redis主从复制架构中，RDB被用作数据同步的一种机制。主节点可以生成RDB文件，然后发送给从节点，用于初次全量复制或连接重建时的快速同步。
• 恢复和备份 ：RDB 文件是一个紧凑的二进制文件，可以很方便地进行备份、传输和恢复。
• 缓存层 ：作为数据库缓存时，如果数据丢失，可以重新获取并填充到缓存中。

在redis.conf中开启RDB：

# 关闭
# save "" 
# 开启，每隔600秒（10分钟）检查一次，如果在这段时间内至少发生了10次写操作，则执行一次RDB快照保存
save 600 10

存入数据后，关闭Redis 时，会触发生成RDB文件。重启时会重新加载到内存中。执行多次写入操作，可以看到触发了保存规则，开启了子线程进行RDB生成：

总结 ：可以接受在灾难情况下丢失几分钟的数据。

2.3 AOF

AOF 相较于 RDB 其主要缺点就是性能不如 RDB，适用于数据一致性要求较高的场景。默认情况下是关闭的，需要在redis.conf中主动开启：

# 关闭 RDB
save "" 
# 开启AOF
appendonly yes

重启 Redis 后，在控制台可以看到创建了AOF 的基础文件和增量文件：

在 appendonlydir （默认存储目录）下可以看到相关文件：

2.4 混合模式

RDB、AOF 各有特点，在技术选型时是一个权衡点，其特点对比如下：

在官方文档中，有提到如果想要获得与 PostgreSQL 级别的数据安全性，应该同时使用两种持久化方式。

2.4.1 方式一： 同时开启

在配置文件中同时开启RDB、AOF持久化：

# 开启RDB
save 600 10
# 开启AOF
appendonly yes

当触发了规则后，会同时生成RDB、AOF文件：

这种方式下，同时维护两套持久化机制，对性能会造成一定的影响。

2.4.2 方式二： 只开启 AOF

AOF 本身已经提供了混合持久化机制，在之前的《Redis持久化-AOF》中有介绍过一个配置参数：

aof-use-rdb-preamble yes

在 Redis 6 中，开启此配置后（默认开启），重写 的AOF 文件由两个不同的部分组成：

• RDB file：数据快照
• AOF tail：记录写操作

在重启加载过程中，Redis 会识别 AOF 文件以 “REDIS” 字符串开头，并加载 RDB 快照数据，然后继续加载 AOF相关的内容，以实现更快的重写和恢复速度。

在 Redis 7 中，开启此配置后（默认开启），在 AOF 重写时，会将当前时刻的数据快照保存为单个的 RDB文件，后续的写操作也保存为单独的 AOF 文件：