Redis持久化策略剖析

持久化策略

Redis提供了RDB持久化、AOF持久化、RDB-AOF混合持久化三种持久化策略。

1、RDB持久化

RDB持久化是Redis默认持久化方式，可以通过SAVE或BGSAVE命令触发，也可以通过配置选项，让服务器在保存条件满足时执行BGSAVE命令，最终生成一个二进制RDB文件，文件中保存了数据库中的所有键值对。

• SAVE命令会阻塞当前进程，直到RDB文件创建完毕，在此期间服务器无法响应请求。
• BGSAVE命令会fork一个子进程，让子进程创建RDB文件，父进程继续响应请求。在BGSAVE执行期间，客户端发送的SAVE和BGSAVE请求都会被服务端拒绝。

RDB持久化的优缺点分析：

• 优点：RDB文件是一个经压缩的二进制文件，体积小，使用该文件恢复数据的速度非常快。
• 缺点：BGSAVE每次运行都要执行fork操作创建子进程，属于重量级操作，不宜频繁执行，无法做到实时持久化，因此可能会丢失大量数据。

2、AOF持久化

AOF，即Append Only File，文件中保存了服务器执行的所有写命令。

AOF持久化的实现分为三个步骤：命令追加、文件写入和文件同步。

• 命令追加

AOF功能开启时，服务器在执行完写命令后会将其追加到一个名为aof_buf的缓冲区末尾。

• 命令写入

Redis的服务进程就是一个循环，每当执行到文件事件处理函数时，就会根据配置文件的appendfsync选项判断当前是否需要将aof_buf的内容写入到AOF文件中，判断方法如下：

• 文件同步

即调用系统函数fsync()或fdatasync()，强制将文件缓冲区的内容刷新到磁盘。

AOF重写原理：

随着命令越来越多，AOF文件也会逐渐膨胀。为此，Redis提供了BGREWRITEAOF命令执行AOF文件重写的功能。

当执行BGREWRITEAOF时，Redis服务端会创建一个子进程，该进程负责直接读取数据库中的键值对，生成对应的命令，后期恢复时可以通过该命令生成一个相同的键值对，达到恢复整个数据库的目的。

在子进程重写AOF时，会创建一个AOF重写缓冲区，如果有的键值对在重写期间被修改，此时服务器就会将这个修改命令写入到重写缓冲区中，方便子进程实时修改重写的AOF文件。

AOF持久化的优缺点分析：

• 优点：与RDB持久化可能丢失大量的数据相比，AOF持久化的安全性要高很多。通过使用everysec选项，用户可以将数据丢失的时间窗口限制在1秒之内。

• 缺点：

  1. AOF是文本文件，它的体积要比二进制格式的RDB文件大很多。
  2. AOF需要通过执行AOF文件中的命令来恢复数据库，其恢复速度比RDB慢很多。
  3. 每个写命令会伴随着Redis服务器将命令写入缓冲区的操作，因此会降低部分性能。

  注：AOF采用文本文件，具有可读性，且避免了二次处理的开销。

3、RDB-AOF混合持久化

• 在执行重写AOF文件时，不再根据键值对生成命令，而是生成RDB文件格式的压缩二进制数据。
• 对于执行重写期间的写命令，以文本格式追加到AOF文件末尾，即压缩二进制数据的后面。

通过使用RDB-AOF混合持久化，用户可以同时获得RDB持久化和AOF持久化的优点，服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作，又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内。