redis持久化的三种方式

Redis 是基于内存的数据库，而内存又是易失性的，一旦遇到断电或异常重启等问题时，内存中的数据就会丢失。所以 Redis 为了保证数据的可靠性花了不少功夫。

Redis 主要是通过 AOF 日志和 RDB 快照来实现持久化的。

Redis 共有三种数据持久化的方式：

• AOF 日志 ：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里；
• RDB 快照 ：将某一时刻的内存数据，以二进制的方式写入磁盘；
• 混合持久化 ：Redis 4.0 新增的方式，集成了 AOF 和 RBD 的优点；

AOF (Append Only File)

Redis 的 AOF 是一种为了数据持久化而设计的日志系统。AOF 持久化会记录每个写操作命令到一个日志文件中，这些命令会在 Redis 重启时被重新执行来重建整个数据集。AOF 持久化提供了一种更加可靠的方式来确保数据不会因为故障而丢失。

AOF 持久化的工作原理

1. 记录命令 ：每当 Redis 执行一个写命令（比如 SET, HSET 等），这个命令会被追加到 AOF 文件的末尾。这确保了所有对数据的更改都会被记录下来。

2. 文件同步策略 ：Redis 提供了几种不同的文件同步策略，让你可以在性能和数据安全性之间做出权衡。这些策略包括：

   • always ：每次写操作后都会同步文件，这提供了最高的数据安全性，但可能会因为磁盘 I/O 的频繁操作而导致性能问题。
   • everysec （默认）：每秒同步一次文件。这提供了一个平衡的选择，既保证了较好的数据安全性，又避免了过多的性能损失。
   • no ：不主动同步文件，只依赖操作系统的缓存策略和周期。这种策略提供了最高的性能，但在系统崩溃的情况下可能会丢失最近一秒钟的数据。

3. 文件重写 ：随着时间的推移，AOF 文件可能会变得非常大，因为它记录了所有的写操作。Redis 提供了 AOF 重写的功能，这个过程会创建一个新的 AOF 文件，其中只包含达到当前数据集状态所需的最小命令集。这有助于减少磁盘空间的占用并提高 Redis 启动时的恢复速度。

4. 恢复数据 ：当 Redis 重启时，它会读取 AOF 文件中的所有命令并重新执行它们，以此来重建整个数据集。这个过程可能需要一些时间，取决于 AOF 文件的大小。

使用 AOF 持久化的优点包括：

• 数据安全性 ：通过记录每个写操作，AOF 提供了很高的数据安全性。
• 灵活性 ：提供了不同的文件同步策略，让用户可以根据自己的需求选择最合适的设置。
• 可读性 ：AOF 文件是纯文本格式的，可以很容易地进行查看和编辑。

但是存在两个风险：

• 执行写操作命令和记录日志是两个过程，如果 Redis 还没来得及将命令写入到硬盘，服务器发生宕机，这个数据就会有 丢失的风险 。
• 由于写操作命令执行成功后才记录到 AOF 日志，所以不会阻塞当前写操作命令的执行，但是 可能会给下一个命令带来阻塞风险 。

然而，使用 AOF 也有一些潜在的缺点，比如可能会对性能产生影响（尤其是在 always 同步模式下），并且在数据集很大时，AOF 文件的重写可能需要较长时间。因此，在使用 AOF 时，合理配置和定期监控是很重要的。

RDB (Redis Database)

Redis Database，即快照/内存快照，RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据（二进制数据，使用 LZF 算法进行压缩），因此在 Redis 恢复数据时， RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。

RDB持久化通过创建数据集的快照来实现，在指定的时间间隔内执行快照操作，将Redis的某一时刻的数据状态保存到磁盘上的一个文件中（通常是dump.rdb文件）。

RDB的工作原理

1. 触发时机 ：RDB持久化可以通过两种方式触发：

   • 根据配置文件中的规则自动触发。例如，可以设定”在900秒内至少有1个键被修改”或”在300秒内至少有10个键被修改”等规则。

     # 在配置文件中使用如"save m n"，表示m秒内数据修改n次,自动触发bgsave。
     save 900 1
     save 300 10
     save 60 10000

   • 手动触发，通过执行SAVE或BGSAVE命令。SAVE命令会阻塞当前Redis服务器直到RDB文件创建完毕，而BGSAVE命令会在后台异步创建RDB文件，这样就不会阻塞主服务器。

2. 创建快照 ：当RDB持久化被触发时，Redis会创建一个数据集的快照。如果是BGSAVE命令，Redis会fork一个子进程来创建这个快照，父进程则可以继续处理客户端的请求。

3. 写入磁盘 ：快照数据会被写入到一个临时RDB文件中。写入过程中，会使用一种高效的压缩算法来减少磁盘空间的占用。一旦整个数据集被成功写入临时文件，这个临时文件会替换掉之前的RDB文件。

RDB的优点包括：

• 快速重启 ：使用RDB恢复数据比使用AOF（Append Only File，另一种Redis持久化机制）的方式要快得多。
• 数据压缩 ：RDB文件是压缩的，占用磁盘空间较小。
  简单性：RDB是一个非常简单的持久化方式，只需要一个文件就能完成数据的恢复。

然而，RDB也有一些缺点：

• 数据丢失风险：如果Redis崩溃，自上次快照以来的所有修改都会丢失。
• 在大数据集上保存快照可能会导致延迟：尽管使用BGSAVE可以减少这种影响，但在快照过程中仍然可能会出现短暂的延迟。
• 主线程修改数据需要复制物理内存，如果所有的共享内存都被修改，则此时的内存占用是原先的两倍。

总的来说，RDB提供了一种快速、高效的方式来恢复Redis数据，但在对数据丢失的容忍度较低的应用中，可能需要与AOF等其他持久化机制结合使用。

混合持久化

Redis 4.0 开始支持混合使用 AOF 日志和内存快照，也叫混合持久化。简单来说就是，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

当开启了混合持久化时，在 AOF 重写日志时，重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

这样的好处在于，重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。