为什么需要持久化？
Redis作为一个纯内存操作的数据库，一旦服务器宕机，内存中的数据将全部丢失。因此，需要将数据持久化，宕机时能够将数据恢复。
AOF(Append Only File, 追加写)日志是如何实现的？
说到日志，我们比较熟悉的是数据库(Mysql Innodb)的写前日志（Write Ahead Log, WAL），也就是说，在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复。不过，AOF 日志正好相反，它是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志，如下图所示：
那 AOF 为什么要先执行命令再记日志呢？要回答这个问题，我们要先知道 AOF 里记录了什么内容。
传统数据库的日志，例如 redo log（重做日志），记录的是修改后的数据(事务的一致性)，而 AOF 里记录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的。
以 Redis 收到“set testkey testvalue”命令后记录的日志为例，看看 AOF 日志的内 容。 其中，"*3"表示当前命令有三个部分，每部分都是由数字开头，后面紧跟着具体的命令、键或值。这里，"数字"表示这部分中的命令、键或值一共有多少字节。例如，"$3 set"表示这部分有 3 个字节，也就是"set"命令。
但是，为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。
而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。
除此之外，AOF 还有一个好处：它是在命令执行后才记录日志，所以不会阻塞当前的写操作。
AOF的潜在风险
- 如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。（总结：数据丢失风险）
- 其次，AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。（总结： 性能影响风险）
- AOF 是以文件的形式在记录接收到的所有写命令。随着接收的写命令越来越多，AOF 文件会越来越 大。这也就意味着，要小心 AOF 文件过大带来的性能问题。（总结： 文件过大、恢复过慢）
前面两个风险都是和 AOF 写回磁盘的时机相关的。
AOF的三种写回策略
对于这个问题，AOF 机制给我们提供了三个选择，也就是 AOF 配置项 appendfsync 的三个可选值。
- Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
- Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲 区，每隔一秒把缓冲区中的内容写入磁盘；
- No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓 冲区，由操作系统决定何时将缓冲区内容写回磁盘。
三种策略的优缺点：
- 对于同步写回而言，虽然基本上不丢数据，但是由于每一个写命令都会有一个慢速的落盘操作，不可避免的会影响到主线程的性能；
- 对于每秒写回而言，虽然减少了对系统性能的影响，但是如果发生了宕机事件，上1秒内未落盘的数据依然会发生丢失；
- 由操作系统控制而言，性能虽然最好，但是丢失数据时也是最多的。
AOF文件过大怎么办？
AOF文件过大导致的性能问题，主要在于以下三个方面：一是，文件系统本身对文件大小有限制， 无法保存过大的文件；二是，如果文件太大，之后再往里面追加命令记录的话，效率也会 变低；三是，如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如 果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用。
这个时候，AOF 重写机制就登场了
AOF重写机制
简单来说，AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文 件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。
为什么重写机制可以把日志文件变小呢? 实际上，重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。
我们知道，AOF 文件是以追加的方式，逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令。但是，在重写的时候，是根据这个键值对当前的最新状态，为它生成对应的写入命令。这样一来，一个键值对在重写日志中只用一条命令就行了，而且，在日志恢复时，只用执行这条命令，就可以直接完成这个键值对的写入了。
不过，虽然 AOF 重写后，日志文件会缩小，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另一个问题了：重写会不会阻塞主线程？
AOF 重写会阻塞吗?
和 AOF 日志由主线程写回不同，重写过程是由后台线程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。(总结：fork子线程时会阻塞， AOF拷贝时不会阻塞)
重写的过程总结为“一个拷贝，两处日志”
“一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。
“两处日志”是什么呢？ 由于主线程没有被阻塞，依然再处理任务，此时，如果有写操作，第一处日志就是指正在使用的AOF日志，redis的写操作依然会写到它的缓冲区；这样以来，即使宕机了，这个AOF日志依然是完毕的，可以用来恢复。
第二处日志是指，在主线程写AOF日志时，这个操作也会写入到AOF的重写缓冲区，等到子进程拷贝完了所有操作记录重写完成后，重写日志缓冲区记录的这些最新操作也会写入新的AOF文件，以保证数据库最新状态的记录，此时就可以用新的AOF文件替换了。
总结来说，每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。
什么时候会触发重写 ROF 文件？
- 主动执行bgrewriteaof命令；
- 主从复制完成RDB文件解析和加载（无论是否成功）。
- AOF重写被设置为待调度执行。
- AOF被启用，同时AOF文件的大小比例超出阈值，以及AOF文件的大小绝对值超出阈值。
- auto-aof-rewrite-percentage：AOF文件大小超出基础大小的比例，默认值为100%，即超出1倍大小。
- auto-aof-rewrite-min-size：AOF文件大小绝对值的最小值，默认为64MB。
虽然AOF重写和RDB创建都用了子进程，但是它们也有不同的地方，AOF重写过程中父进程收到的写操作，也需要尽量写入AOF重写日志，在这里，Redis源码是使用了 管道机制 来实现父进程和AOF重写子进程间的通信的
