redis系列（8）：Redis持久化，RDB和AOF 的区别、混合持久化

关于Redis说点什么，目前都是使用Redis作为数据缓存，缓存的目标主要是那些需要经常访问的数据，或计算复杂而耗时的数据。缓存的效果就是减少了数据库读的次数，减少了复杂数据的计算次数，从而提高了服务器的性能。

一、redis持久化----两种方式

1、redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

2、RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

3、AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

4、其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

5、如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

二、redis持久化----RDB

1、RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

2、redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。

3、对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。

4、如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

5、虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。
 

三、redis持久化----AOF

1、AOF，英文是Append Only File，即只允许追加不允许改写的文件。

2、如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

3、我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

4、AOF也有三种触发机制：默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失

（3）不同no：从不同步

5、如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。

6、因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

7、在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。

8、AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。

9、虽然优点多多，但AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

10、如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异，确认问题点
4.重启redis，加载修复后的AOF文件

 

五、AOF重写机制

随着运行时间的增长，执行的命令越来越多，会导致AOF文件越来越大，当AOF文件过大时，redis会执行重写机制来压缩AOF文件。这个压缩和上面提到的RDB文件的算法压缩不同，重写机制主要是将文件中无效的命令去除。比如：

• 同一个key的值，只保留最后一次写入
• 已删除或者已过期数据相关命令会被去除
  这样就避免了，aof文件过大而实际内存数据小的问题(如频繁修改数据时，命令很多，实际数据很少)

重写的触发方式：

• 手动执行 bgrewriteaof 触发AOF重写
• 在redis.conf文件中配置重写的条件，如：

 

auto-aof-rewrite-min-size 64MB   // 当文件小于64M时不进行重写
auto-aof-rewrite-min-percenrage 100  // 当文件比上次重写后的文件大100%时进行重写

重写的过程

• 从主进程中fork出子进程，并拿到fork时的AOF文件数据写到一个临时AOF文件中
• 在重写过程中，redis收到的命令会同时写到AOF缓冲区和重写缓冲区中，这样保证重写不丢失重写过程中的命令
• 重写完成后通知主进程，主进程会将AOF缓冲区中的数据追加到子进程生成的文件中
• redis会原子的将旧文件替换为新文件，并开始将数据写入到新的aof文件上

关于重写机制需要注意以下几点：

• 执行重写时如果发现有进程正在执行重写，那么直接返回。如果有进程正在执行BGSAVE，那么会等BGSAVE执行完成后再执行重写。
• Redis执行重写时会fork一个进程进行，其开销和RDB一样
• 重写过程不影响原有的AOF过程，write，save操作都不影响
• 重写过程中有几种时刻会阻塞主进程： 在fork子进程时，将重写缓冲区的数据写到磁盘上时，使用新AOF文件替换旧文件时

六、常用配置

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always     #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no          #从不同步。高效但是数据不会被持久化。

 

七、redis持久化----如何选择RDB和AOF

1、对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。

2、redis的备份和还原，可以借助第三方的工具redis-dump。

八、Redis的两种持久化方式也有明显的缺点

1、RDB需要定时持久化，风险是可能会丢两次持久之间的数据，量可能很大。

2、AOF每秒fsync一次指令硬盘，如果硬盘IO慢，会阻塞父进程；风险是会丢失1秒多的数据；在Rewrite过程中，主进程把指令存到mem-buffer中，最后写盘时会阻塞主进程。

3、这两个缺点是个很大的痛点。

九、 混合持久化

重启 Redis 时，我们很少使用 RDB 来恢复数据库状态，因为会丢失大量数据。我们通常使用 AOF 日志重写，但是 AOF 重写性能相对 RDB 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

 通过 redis.conf文件中的 aof-use-rdb-preamble yes  来开启混合持久化，然后重启 Redis 服务。

混合持久化同样也是通过 BGREWRITEAOF  完成的，不同的是当开启混合持久化时，fork 出的子进程先将共享的内存副本全量的以RDB方式写入 AOF 文件，然后在将 aof_rewrite_buf 重写缓冲区的增量命令以 AOF 方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。简单的说：新的AOF文件前半段是 RDB 格式的全量数据后半段是 AOF 格式的增量数据。（关于AOF 重写可以参考 详见 Redis 持久化——AOF 详解 中的章节）

也就是说在原来 AOF 重写之前，先将内存 RDB 快照的内容也写入到新的 AOF 文件中，然后再进行 AOF 重写，最后原子的覆盖旧的 AOF 文件。

AOF 文件格式
AOF根据配置规则在后台自动重写 AOF 文件，也可以人为执行命令 BGREWRITEAOF 重写 AOF。于是在 Redis 重启的时候，先加载 RDB 的内容，然后再执行 AOF 命令部分达到 Redis 数据重放的目的，这样先重写 RDB 到内存，然后在重写 AOF 到内存，重启效率高，还能减少数据的丢失。

缺点：兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该 AOF 文件，同时由于前部分是 RDB 格式，阅读性较差