Redis 持久化机制

持久化数据，也就是将内存中的数据写入到硬盘里，大部分原因是为了之后重用数据（比如重启机器、机器故障后恢复数据），或是为了防止系统故障而将数据备份到远程。

Redis 不同于 Memcached 的重要一点就是，Redis 支持持久化，且支持两种不同的持久化操作。

默认的持久化方式叫快照（snapshotting，RDB），另一种方式是只追加文件（append-only file，AOF）。

快照（snapshotting）持久化（RDB）

Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，或者将快照复制到其他服务器，从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地，以便重启服务器的时候使用。

快照持久化是 Redis 默认采用的持久化方式，在 redis.conf 配置文件中默认有此下配置：

save 900 1           # 900秒(15分钟)后，如果至少有1个key发生变化，Redis 就会自动触发 BGSAVE 命令创建快照
save 300 10          # 300秒(5分钟)后，如果至少有10个key发生变化，Redis 就会自动触发 BGSAVE 命令创建快照
save 60 10000        # 60秒(1分钟)后，如果至少有10000个key发生变化，Redis 就会自动触发 BGSAVE 命令创建快照

AOF（append-only file）持久化

与快照持久化相比，AOF 持久化的实时性更好，因此已成为主流的持久化方案。默认情况下 Redis 是没有开启 AOF（append only file）方式的持久化，可以通过 appendonly 参数开启：

appendonly yes

开启 AOF 持久化后，每执行一条会更改 Redis 中的数据的命令，Redis 会将该命令写入硬盘中的 AOF 文件。AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof。

在 Redis 的配置文件中，存在三种不同的 AOF 持久化方式，分别是：

appendfsync always    # 每次有数据修改发生时都会写入 AOF 文件,这样会严重降低 Redis 的速度
appendfsync everysec  # 每秒钟同步一次，显示地将多个写命令同步到硬盘（推荐）
appendfsync no        # 让操作系统决定何时进行同步

为兼顾数据和写入性能，应当首先考虑 appendfsync everysec 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

Redis 4.0 对于持久化机制的优化

Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式而不再是 AOF 格式，可读性较差。

AOF 重写

AOF 重写可以产生一个新的 AOF 文件，这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。

AOF 重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。

在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。