[ 参考文献 ] : https://juejin.cn/post/6844903939339452430

RDB快照持久化

​ RDB持久化会生成RDB文件，该文件是一个压缩过的二进制文件，可以通过该文件还原快照时的数据库状态，即生成该RDB文件时的服务器数据。

​ RDB文件默认为当前工作目录下的dump.rdb

触发方法

  • 执行save和bgsave命令：save会阻塞redis服务器进程，bgsave会fork一个子进程（见图），服务器进程会继续处理命令请求；
  • 配置文件设置save <seconds> <changes>规则，自动间隔性执行bgsave命令：seconds秒内，至少有changes次变化，就会自动触发bgsave命令；
  • 主从复制时，从库全量复制同步主库数据，主库会执行bgsave；
  • 执行flushall命令清空服务器数据；
  • 执行shutdown命令关闭Redis时，会执行save命令。
img

AOF持久化

​ AOF（Append Only File）持久化功能，AOF持久化会把被执行的写命令（Redis的序列化协议RESP）写到AOF文件的末尾，记录数据的变化。

​ 默认情况下，Redis是没有开启AOF的，开启后，每执行一条更改Redis数据的命令，都会把该命令追加到AOF文件中，这是会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外SSD可以提高AOF的性能。

文件写入(write)和文件同步(fsync)

操作系统的write命令会缓冲限流，fsync会强制写硬盘但是效率较低，Redis提供了以下fsync策略：

  • appendfsync always：每个写命令同步写入磁盘
  • appendfsync everysec（默认值）：将aof_buf缓存区的内容写入AOF文件，每秒同步一次，该操作由一个线程专门负责
  • appendfsync no：由操作系统来决定写入文件

AOF重写

​ AOF文件中通常会有一些冗余命令，如：过期数据的命令、无效的命令（重复设置、删除）、多个命令可合并为一个命令（批处理命令）。故AOF提供了压缩空间的重写命令（流程见下图），有以下触发方式：

  • 手动触发：bgrewriteaof，与bgsave触发快照时类似的，都是fork一个子进程执行；

  • 自动触发会：根据以下参数配置来自动执行bgrewriteaof命令：

   # 表示当AOF文件的体积大于64MB，且AOF文件的体积比上一次重写后的体积大了100%时，会执行`bgrewriteaof`命令
   auto-aof-rewrite-percentage 100
   auto-aof-rewrite-min-size 64mb
img

RDB和AOF优缺点

RDB

优点

  • 保存着某个时间点的完整数据集，适合做数据的备份，灾难恢复；
  • 可以最大化Redis的性能，只需fork一个子进程来完成RDB文件的创建，父进程不需要做IO操作；
  • 与AOF相比，恢复大数据集的时候会更快；

缺点

  • 数据安全性不如AOF，根据配置可能要几分钟才快照一次，如果服务器宕机，就可能丢失几分钟的数据；
  • Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时；

AOF

优点

  • 数据更完整，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）；
  • AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容可读，适合误删紧急恢复；

缺点

  • 对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢；
  • 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。 不过在一般情况下，每秒 fsync 的性能依然非常高。