【Redis经典面试题六】Redis的持久化机制是怎样的？

一、Redis的持久化机制

[1.1 RDB](#1.1 RDB)

[1.2 AOF](#1.2 AOF)

[1.3 比较](#1.3 比较)

[1.4 混合持久化](#1.4 混合持久化)

[二、RDB 和 AOF 的写回策略分别是什么？](#二、RDB 和 AOF 的写回策略分别是什么？)

[2.1 RDB的写回策略](#2.1 RDB的写回策略)

定期触发

手动触发

[2.2 AOF 的写回策略](#2.2 AOF 的写回策略)

三、Redis能完全保证数据不丢失吗？

一、Redis的持久化机制

Redis提供了两种持久化的机制，分别是RDB和AOF。

1.1 RDB

RDB是将Redis的内存中的数据定期保存到磁盘上，以防止数据在Redis进程异常退出或服务器断电等情况下丢失。

RDB的优点是：快照文件小、恢复速度快，适合做备份和灾难恢复。

RDB的缺点是：定期更新可能会丢数据

1.2 AOF

AOF是将Redis的所有写操作追加到AOF文件（Append Only File）的末尾，从而记录了Redis服务器运行期间所有修改操作的详细记录。当Redis重新启动时，可以通过执行AOF文件中保存的写操作来恢复数据。

但是如果Redis刚刚执行完一个写命令，还没来得及写AOF文件就宕机了，那么这个命令和相应的数据就会丢失了。但是他也比RDB要更加靠谱一些。

AOF的优点是：可以实现更高的数据可靠性、支持更细粒度的数据恢复，适合做数据存档和数据备份。

AOF的缺点是：文件大占用空间更多，每次写操作都需要写磁盘导致负载较高。

1.3 比较

RDB 和 AOF 在数据可靠性、性能、存储空间占用等方面都有不同的优缺点，具体可以根据实际业务需求和硬件条件来选择合适的持久化机制，或者同时使用两种持久化机制来实现更高的数据可靠性。

特性	RDB	AOF
数据可靠性	可能会丢失最后一次快照之后的数据	保证最后一次写操作之前的数据不会丢失
性能	读写性能较高，适合做数据恢复	写性能较高，适合做数据存档
存储空间占用	快照文件较小，占用空间较少	AOF 文件较大，占用空间较多
恢复时间	从快照文件中恢复数据较快	从 AOF 文件中恢复数据较慢

1.4 混合持久化

AOF 和 RDB 各自有优缺点，为了让用户能够同时拥有上述两种持久化的优点，Redis 4.0 推出了 RDB-AOF 混合持久化。

在开启混合持久化的情况下，AOF 重写时会把 Redis 的持久化数据，以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式追加到文件的末尾。

aof-use-rdb-preamble 是开启混合模式的参数。

混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快地启动，同时结合 AOF 的优点，又减低了大量数据丢失的风险。

但是，在 AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；如果开启混合持久化，那么此混合持久化 AOF 文件，是不能用在旧版本中的，不向下兼容的。

二、RDB 和 AOF 的写回策略分别是什么？

写回策略是指将数据从内存写入到持久化存储（如磁盘）的方式和时机。在 Redis 中，不同的持久化机制有着不同的写回策略。

2.1 RDB的写回策略

在 Redis 中，RDB 的写回策略主要包括以下几个方面：

定期触发

Redis 通过配置文件中的 save 参数定义了 RDB 的自动保存条件。以下是默认配置的示例：

复制代码

save 900 1    # 如果 900 秒内至少有 1 个键发生变化，则保存快照
save 300 10   # 如果 300 秒内至少有 10 个键发生变化，则保存快照
save 60 10000 # 如果 60 秒内至少有 10000 个键发生变化，则保存快照

策略

Redis 会定期检查这些条件，如果满足，触发 RDB 的保存操作。
条件可以通过修改 redis.conf 文件自定义，也可以通过命令动态设置，例如：

CONFIG SET save "300 10 60 10000"

手动触发

在 Redis 中，我们可以通过以下命令手动生成 RDB 文件：

SAVE：会阻塞 Redis 服务器，直到快照完成。
BGSAVE：在后台异步生成 RDB 文件，不会阻塞 Redis。

SAVE 操作直接在主线程完成，不适合生产环境。BGSAVE 会 fork 一个子进程生成快照，更高效，但需要一定的系统资源（如内存和 CPU）。

2.2 AOF 的写回策略

AOF 有三种数据写回策略，分别是 Always、Everysec 和 No。

Always：同步写回。每个写命令执行完，立马同步地将日志写回磁盘。
Everysec：每秒写回。每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘。
No：操作系统控制的写回。每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

"同步写回"可靠性肯定是最高的，但是它在每一个写命令后都有一个落盘操作，而且还是同步的，这和直接写磁盘类型的数据库有啥区别？

"操作系统控制的写回"这种是最不靠谱的，谁知道操作系统啥时候帮你做持久化，万一没来及持久化就宕机了，不就 gg 了。

"每秒写回"是在二者之间折中了一下，异步的每秒把数据写会到磁盘上，最大程度的提升效率和降低风险。

三、Redis能完全保证数据不丢失吗？

Redis提供了两种持久化的机制，分别是RDB和AOF。AOF和RDB各自有优缺点，为了让用户能够同时拥有上述两种持久化的优点，Redis 4.0推出了RDB-AOF混合持久化。

在开启混合持久化的情况下，AOF重写时会把Redis的持久化数据，以RDB的格式写入到AOF文件的开头，之后的数据再以AOF的格式追加到文件的末尾。

那么，有了这个机制之后，能保证Redis的数据一定不丢吗？

不能！

首先Redis是基于内存存储的，虽然有了RDB和AOF的持久化机制，当Redis进程异常退出或服务器断电等情况发生时，内存中的数据可能会丢失。

有一种极端情况，那就是AOF这个持久化方案中，有一种Always的写回策略，即同步写回。也就是说每个写命令执行完，立马同步地将日志写回磁盘。

但是即使是在 always 策略下，也不能保证 100% 不丢失数据的，主要出于以下原因：

磁盘和系统故障：如果在写入操作和同步到磁盘之间发生硬件故障或系统崩溃，可能会丢失最近的写操作。
操作系统缓冲区：即使 Redis 请求立即将数据同步到磁盘，操作系统的 I/O 缓冲区可能会导致实际写入磁盘的操作延迟发生。如果在写入缓冲区之后，没写磁盘前，机器挂了，那么数据就丢了。

操作系统缓冲区，通常指的是操作系统用于管理数据输入输出（I/O）的一种内存区域。当程序进行文件写入操作时，数据通常首先被写入到这个缓冲区，而不是直接写入到硬盘。
磁盘写入延迟：磁盘的写入并非实时完成，特别是在涉及到机械硬盘时，写入延迟主要由磁盘旋转速度（RPM）和寻道时间决定。如果在这个延迟过程中，机器挂了，那么数据也就丢了。

归根结底，Redis 就不是用来干持久化的。要持久化，就用关系型数据库。