Redis 之 RDB 与 AOF

一、前述

持久化都不陌生，mysql 存储就是最经典的持久化，其实也就是把我们想要的数据长久的保存在磁盘上
Redis 提供了两种不同的持久化选项：
1、RDB 持久化在指定的时间间隔执行数据集某个时间点的快照
2、AOF 持久化会记录服务器收到的每个写操作，并且在 server 重启的时候重新被释放加载，重新建立一个数据集，命令使用跟 Redis 本身协议相同的格式记录，使用追加的方式。当 AOF 文件太大的时候，Redis 能够在后台重写日志
3、 如果开发者只是希望数据集在服务器运行时一直存在，可以关闭持久化，不再使用
4、可以在同一个实例中合并 AOF 和 RDB ，值得注意的是，如果这样做了，在重启服务的时候，AOF 文件将被用来建立原始的数据集，因为 AOF 文件是可以保证最完整的数据集

二、RDB 优势

1、RDB 是某个时刻非常紧凑的单文件 Redis 数据，RDB 文件非常适合备份，例如，可以在过去的 24 小时内，每小时归档一次 RDB 文件，在 30 天内，每天保存一个 RDB 文件，这样的话，就允许开发者在灾难发生的时候，很容易的恢复不同版本的数据集
2、RDB 有利于灾难恢复，可以作为单个压缩文件传输到的远程数据中心或者保存在 Amazon s3
3、RDB 最大程序的提高了 Redis 的性能，持久化的时候，父进程会 fork 一个子进程做其他的事情，父进程不需要执行 磁盘 IO 或者类似的操作
4、相比于 AOF ，RDB 允许很快的启动一个很大的数据集

三、RDB 缺点

1、如果在 Redis 停止工作（例如断电）的时候，对数据的丢失要求很小的话， RDB 表现不那么好，可以在配置不同的 RDB 生成规则（例如五分钟以内至少发生 100 次写操作的时候），可以设置多个规则，你通常会每五分钟或更长时间创建一个RDB快照，当 Redis 没有正确得停止时，会丢失最近一部分时间的数据
2、RDB 经常需要 fork（）出一个子进程来进行持久化，当数据集很大的时候，fork（） 将会消耗很多的时间，造成 cpu 不能很好的进行任务调度，这样的话，Redis 将会在一段时间内暂停对客户端的服务，AOF 也需要 fork()，但是开发者可以调整文件重写的频率，不需要牺牲持久化

四、AOF 优点

1、使用 AOF ，Redis 能做到更好的持久化，开发者可以使用不同的 fsync 策略：不进行 fsync，每秒一次 fsync ，每次操作进行 fsync ,一直以来选择默认的每秒一次 fsync 都是不错的选择，当进程中没有 fsync 的时候，fsync 会被后台线程来执行，而主线程依然执行写操作，这样只会丢失很少一部分写入的数据
2、AOF 是用追加日志来记录的，所以在断电的时候，不会有什么损坏的问题，即使在写的时候，因为磁盘满了或者其他的原因，只写入了一半，可以使用 redis-check-aof 很快的修复
3、当 AOF 文件很大的时候，Redis 能够在后台自动重写 AOF，重写是完全安全的，Redis 会继续把追加的旧的文件，根据创建当前数据集所需的最小操作集生成一个全新的数据集，一旦第二个文件准备好了以后，Redis 会切换两个文件，并且会把新的操作日志追加到新的文件
4、AOF 用一种容易理解和解析的格式包含着一个连着一个的操作日志，开发者甚至可以很简单的导出 AOF 文件

五、AOF 缺点

1、对于相同的数据集，AOF 文件的大小通常大于等效的 RDB 文件
2、加载 AOF 会比 RDB 更慢，一般来说设置 fsync 规则为每秒一次一直都是比较高效的做法，禁用 fsync 以后即使在高负载下，它的速度也和RDB一样快，尽管如此，RDB 仍然能为最大延迟提供更多保证，即使在写负载很大的情况下也是如此
3、在执行一些指定的命令时（有例如像 BRPOP、LPUSH 这样的阻塞命令）会导致生成的 AOF 在重新加载时不能完全复制相同的数据集，但是在 RDB 中，是不会有这种问题存在的，因为 RDB 快照每次都是重新创建一个新的快照，从概念上来说，有很其强的健壮性。值得注意的是，AOF 重写每次都是读取旧的 AOF 文件，而不是直接读取内存里的

六、如何使用

1、一般来说，如果想要相当高的数据安全性，应该两种持久化方法都使用
2、如果能够容忍在发生数据库灾难时，丢失一部分数据，可以使用 RDB 快照的方法
3、很多开发者喜欢只用 AOF 的持久化方式，但是不鼓励这样做，经常使用RDB快照对于进行数据库备份、更快地重启以及在AOF 出现问题的时使用 RDB 快照是一个很好的主意
4、redis 4.0 版本推出了混合持久化的模式

七、快照 RDB

1、默认情况下，Redis 将数据持久化在磁盘上一个叫 dump.rdb 的二进制文件中，可以在配置文件中配置 多少秒内至少发生多少次改变的时候，就进行一次数据集保存，也可以在 Redis-cli 手动的使用 save 或者 bgsave 命令来设置，例如：

save 60 1000

代表着如果 60s n内至少有1000个键被更改，这个配置将使 Redis 自动将数据集转储到磁盘，这种策略就叫做快照
2、每次 Redis 将数据集 dump 到磁盘的时候，都会发生下面几个过程：
（1）Redis forks 的时候，必须要有一个子进程和父进程
（2）子进程将数据集写到一个临时的 RDB 文件里
（3）当子进程将数据集完全写到一个新的 RDB 文件里的时候，就会替换掉旧的的 RDB 文件

八、AOF 文件

1、快照不是能做到完全的持久化，如果你的电脑停止运行 Redis 了，或者误操作 kill -9 杀掉了实例的进程，就会丢失最新的数据集，对于有些需要完全持久化的应用来说，RDB 快照不是一个可行的方案
2、AOF 文件是一种可行的完全的持久化策略，在 1.1 版本开始可用，可在配置文件里找到如下配置，来打开 AOF 持久化

appendonly yes

这样，每当 Redis 接收到更改数据集(例如 SET )的命令时，它都会将其附加到 AOF 文件里面去。重新启动 Redis 时，就会释放 AOF 文件来重建数据集

九、日志重写

1、AOF 文件会随着写操作而变得越来越大，例如，自增一个计算器一百次，那么在数据集里面会得到一个最终操作之后的 key 值，但是在 AOF 文件里，有关于这个 key 的 100 个操作记录，在重建数据集的时候是不需要用到这前面 99 次的记录。
2、针对上述的情况，Redis 推出了一个非常有意思的功能：不断开服务端与客户端的连接，在后台进行 AOF 的重写，发起BGREWRITEAOF 命令时，Redis 都将编写重建内存中当前数据集所需的最短命令序列。如果是在 Redis 2.2 中使用 AOF，则需要经常运行 BGREWRITEAOF。Redis 2.4 能够自动触发日志重写

十、AOF 文件如何持久化

我们可以自己配置 Redis 持久化的频率或者策略，有三种策略可供配置：

appendfsync always: 每次更新数据集都将操作写入文件，非常慢，但是很安全
appendfsync everysec: 每秒一次，这种策略足够快，在 2.4 版本中，近似的跟快照一样快，当发生灾难时，只会丢失一秒的数据
appendfsync no: 不做 fsync ,这是更快更不安全的方法。正常情况下，Linux将使用这种配置每30秒刷新一次数据，但这取决于内核的精确

Redis 官方建议使用每秒一次的策略来做持久化，同时也是默认的策略，这种策略同样很快也足够安全