redis 持久化详解,RDB和AOF是什么？他们优缺点是什么？运行流程是什么？

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF持久化（原理是将Reids的操作日志以追加的方式写入文件）。

1. RDB是什么

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

2.触发机制

触发RDB持久化过程分为手动触发和自动触发。
手动触发分别对应save和bgsave命令：

save：会阻塞redis服务器进程，直到创建RDB文件完毕为止；（在此期间进程不能处理任何请求）
bgsave：fork一个子进程来创建RDB文件，父进程可以继续处理命令请求；

save命令：阻塞当前Redis服务器，之道RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，先上环境不建议使用。运行save命令对应Redis日志如下：

DB saved on disk

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一段时间很短。运行bgsave名字对应的Redis日志如下：

Background saving started by pid 3152
DB saved on disk
RDB: 0MB of memory userd by copy-on-write
Background saving terminated with success

;
bgsave命令是针对save阻塞问题做的优化。因此Redis内部所有涉及到RDB操作都采用bgsave的方式，而save命令可以废弃。

Redis内部还存在自动触发RDB的持久化机制，例如一下场景:

2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。

3）执行debug reload命令重新加载Redis时，也会自动触发save操作。
4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

2. AOF是什么

AOF持久化是通过保存redis服务器所执行的写命令来记录数据库状态的；被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的（Redis的请求协议是纯文本的）。服务器在启动时，通过载入AOF文件、并执行其中的命令来还原服务器状态。

命令追加：服务器在执行玩一个写命令后，会以协议的格式把其追加到aof_buf缓冲区末尾；
文件写入：redis服务器进程就是一个事件循环，在每次事件循环结束，会根据配置文件中的appednfsync属性值决定是否将aof_buf中的数据写入到AOF文件中；

appendfsync选项：

我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）

appendonly yes //启用aof持久化方式

appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐

#appendfsync no //完全依赖os，性能最好,持久化没保证

1.流程如下：

1） 所有的写入命令会追加到aof_buf（缓冲区）中。

2） AOF缓冲区根据对应的策略向硬盘做同步操作。

3） 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4） 当Redis服务重启时，可以加载AOF文件进行数据恢复。了解AOF工作流程之后，下面针对每个步骤做详细介绍。

2.重写机制

AOF重写：
为了解决AOF文件体积膨胀问题，redis服务器使用了AOF重写功能：创建一个新的AOF文件来代替现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件体积会比旧AOF文件体积小很多。
原理：
AOF文件重写并不需要对现有AOF文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。首先，从数据库中读取键现在的值，然后使用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写的原理。
步骤：
Redis 执行 fork() ，现在同时拥有父进程和子进程。
子进程开始将新 AOF 文件的内容写入到临时文件。对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

AOF重写过程可以手动触发和自动触发：

手动触发：直接调用bgrewriteaof命令

自动触发：更具auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB

auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值

如果 AOF 文件出错了，怎么办？

为现有的 AOF 文件创建一个备份。
使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
$ redis-check-aof --fix
（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。
AOF 的运作方式
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。