1、保存逻辑：
当 AOF 持久化功能处于打开状态时， 服务器在执行完一个写命令之后， 会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。
服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性。
当 appendfsync 的值为 always 时， 服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 并且同步 AOF 文件， 所以 always 的效率是 appendfsync 选项三个值当中最慢的一个， 但从安全性来说， always 也是最安全的， 因为即使出现故障停机， AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
当 appendfsync 的值为 everysec 时， 服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 并且每隔超过一秒就要在子线程中对 AOF 文件进行一次同步： 从效率上来讲， everysec 模式足够快， 并且就算出现故障停机， 数据库也只丢失一秒钟的命令数据。
当 appendfsync 的值为 no 时， 服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 至于何时对 AOF 文件进行同步， 则由操作系统控制。
因为处于 no 模式下的 flushAppendOnlyFile 调用无须执行同步操作， 所以该模式下的 AOF 文件写入速度总是最快的， 不过因为这种模式会在系统缓存中积累一段时间的写入数据， 所以该模式的单次同步时长通常是三种模式中时间最长的： 从平摊操作的角度来看， no 模式和 everysec 模式的效率类似， 当出现故障停机时， 使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。
2、还原数据逻辑：
1.创建一个不带网络连接的伪客户端（fake client）。
2.读取 AOF 所保存的文本，并根据内容还原出命令、命令的参数以及命令的个数。
3.根据命令、命令的参数和命令的个数，使用伪客户端执行该命令。
4.执行 2 和 3 ，直到 AOF 文件中的所有命令执行完毕。
完成第 4 步之后， AOF 文件所保存的数据库就会被完整地还原出来。
3、aof重写、BGREWRITEAOF实现原理
aof重写不需要对旧的文件执行操作
AOF重写程序aof_rewrite函数可以很好完成创建一个新AOF文件的任务，但是这个函数会进行大量写入操作，会长时间阻塞，所以Redis将AOF重写程序放到子进程里执行，这样做达到两个目的：
·子进程AOF重写期间，服务器进程可以继续处理命令请求。
·子进程带有数据库进程的数据副本，使用子进程而不是线程，可以避免使用锁的情况下保证数据安全。
不过，使用子进程也有一个问题需要解决，就是AOF重写期间如果有新的写命令进来，不能漏掉，那样会数据不一致。
于是Redis服务器设置了一个AOF重写缓冲区
从创建子进程开始，服务器执行的所有写命令会被记录到AOF重写缓冲区里面
最后流程变为：
1.执行客户端发来的命令
2.将执行的写命令追加到AOF缓冲区
3.将执行后的写命令追加到AOF重写缓冲区
当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父进程收到信号后，会调用一个信号处理函数，并执行以下工作：
1.将AOF重写缓冲区中的所有内容写入新的AOF文件中，这时新AOF文件锁保存的数据库状态和服务器当前状态一致
2.对新的AOF文件进行改名，原子性操作地覆盖现有的AOF文件，完成新旧AOF文件的替换。
这个信号函数执行完毕以后，父进程就可以继续像往常一样接受命令请求了，在整个AOF后台重写过程中，只有信号处理函数执行时会对服务器进程造成阻塞，其他时候都可以继续处理请求，这样AOF重写对服务器性能造成的影响降到了最低。
重点回顾
·AOF文件通过保存所有修改数据库的写命令来记录服务器的数据库状态
·AOF文件中所有命令都以Redis命令请求协议的格式保存
·命令请求会先保存到AOF缓冲区里面，之后再定期写入并同步到AOF文件。
·appendfsync选项的不同值对AOF持久化功能的安全性以及Redis服务器的性能有很大的影响
·服务器只要载入并重新执行保存在AOF文件中的命令，就可以还原数据库本来的状态
·AOF重写可以产生一个新的AOF文件，这个新的AOF文件就是当前数据库状态的dump，所以垃圾冗余数据被清理了
·AOF重写是一个有歧义的名字，该功能是通过dump数据库所有建值对实现的，程序无需对现有AOF文件进行任何操作。
·执行BGREWRITEAOF命令时，Redis服务器会维护一个AOF重写缓冲区，以保证数据一致性。
