Redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，也容易发生丢失。为此，Redis提供了来着持久化的机制，分别为RDB和AOF。

RDB机制-半持久化模式

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，是实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。

sava触发方式

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

bgsava触发方式

Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

自动触发

自动触发是由我们的配置redis.conf文件来完成的。
默认如下配置：

  • 表示900 秒内如果至少有 1 个 key 的值变化，则保存save 900 1
  • 表示300 秒内如果至少有 10 个 key 的值变化，则保存save 300 10
  • 表示60 秒内如果至少有 10000 个 key 的值变化，则保存save 60 10000

RDB优缺点

优点

  • 只有一个文件 dump.rdb，恢复操作简单，容灾性好
  • 性能较高，fork 子进程进行写操作，主进程继续处理命令
  • 大数据集比 AOF 的恢复效率高

缺点

  • 数据安全性低，RDB 是每间隔一段时间进行持久化，若期间 redis 发生故障，可能会发生数据丢失

AOF机制-完全持久化模式

全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件 aof 文件中。通俗的理解就是日志记录。
redis默认是关闭的，我们需要在redis.config中将其开启，其持久化名称为appendonly.aof。

appendonly yes

AOF优缺点

优点

  • AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据
  • 数据安全，aof 持久化可以配置 appendfsync 属性为 always，记录每个命令操作到 aof 文件中一次，通过 append 模式写文件，即使中途服务器宕机，也可以通过 redis-check-aof 工具解决数据一致性问题
  • AOF 机制的 rewrite 模式，AOF 文件没被 rewrite 之前可以进行处理，如删除文件中的 flushall 命令

缺点

  • AOF 的持久化文件比 RDB 大，恢复速度慢
  • AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

RDB与AOF如何选择

需求不同选择的也不同，通常都是结合使用，当同时开启时，redis优先加载AOF持久化数据。