之前我们提及到了redis的默认持久化方式RDB，是一种通过存储快照数据方式持久化的机制，它在宕机后会丢失掉最后一次更新RDB文件后的数据，这也是由于它只关注于数据结果导致的。那么我们思考一下，有没有一种方式能够把数据存储、修改、删除这种变化的过程记录下来，也就是记录那些set，hset,del语句，等到redis重启后直接执行一遍这些语句即可，由此来达到数据恢复的效果呢？这样的话是不是就不会过多的丢失数据呢？由于是记录的过程，它可能仅仅会丢失宕机时的那一刻那一秒的数据而已。此刻，一种补充性的持久化机制AOF应运而生了，它就是一种只关注过程不关注结果的持久化机制。

AOF

AOF（append only file）是redis持久化的另一种机制，在默认情况下是不开启的。根据英文append only file 翻译成英文的意思：仅仅追加文件，意思是不断的去追加记录那些写入命令写入文件中，可以明白这是一个过程的记录。

? 当redis开启AOF持久化后，redis将所有对数据库进行过的写入的命令（及其参数）记录到AOF文件，以此达到记录数据库状态的目的。

? 也就是说当redis重启之后只要按顺序回放这些命令就会恢复到原始状态了。

? 再重申一遍，AOF会记录过程，RDB只管结果。

AOF的持久化实现

通过配置redis.conf来进行开启和其他的一些设置

# 可以通过修改redis。conf配置文件中的appendonly参数开启
appendonly yes

#AOF文件的保存位置和ROB文件的保存位置相同，通过dir ./参数设置的
dir ./

#默认的文件名是appendonly.aof, 可以通过appendfilename参数修改
appendfilename appendonly.aof

AOF原理

AOF文件中存储的是redis的命令，同步命令到 AOF 文件的整个过程可以分为三个阶段，他们分别是：命令传播，缓存追加，文件写入和保存。

• 命令传播：当redis的客户端执行命令时，它会通过网络连接，将协议文本发送给redis的服务器，服务器会根据协议文本里面的内容，选择适当的命令函数，将各个参数从文本转换为redis的字符串对象。命令执行成功后，命令参数就会被传播到AOF程序。
• 缓存追加：AOF程序接受到那些命令参数，数据啥的，又会转换为原来的协议文本，协议文本生成之后就会被追加到redis.h/redisServer 结构的 aof_buf 末尾。也就是把协议内容追加到了服务器的AOF缓存里面了。
• 文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话， fsync 函数或者fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。（解释：每当服务器常规任务函数被执行、 或者事件处理器被执行时， aof.c/flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作：WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。）

AOF保存模式

Redis目前支持三种的AOF保存模式，他们分别是：

• AOF_FSYNC_NO:不保存
• 调用flushAppendOnlyFile函数，WRITE都会被执行，但SAVE会被忽略。
• AOF_FSYNC_EVERYSEC:每一秒保存一次。（默认）
• 在这种模式中， SAVE 原则上每隔一秒钟就会执行一次， 因为 SAVE 操作是由后台子线程（fork）调用的， 所以它不会引起服务器主进程阻塞。
• AOF_FSYNC_ALWAYS:每执行一个命令保存一次。（不推荐，极大影响redis效率）
• 每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。
• 因为save是由主进程执行的，所以在执行期间，主进程会被阻塞，不能接受命令请求。

AOF重写机制

AOF不断的记录数据的变化过程，时间一长，数据就会越来越多，它就得需要重写一下，进行数据的瘦身，所谓AOF重写，无非就是把针对于某个数据的操作去除中间过程，只保留起始即可，毕竟我们想恢复的是一个最终态。举个例子帮助理解：

很明显，重写后的AOF文件记录的比没有重写的少记录两行，大大节省空间。

Redis不希望AOF重写造成服务无法处理请求，所以redis决定将重写程序放在子进程里面执行，这样做有几个好处：

• 1.子进程进行AOF重写，不影响主程序处理其他的命令请求。
• 2.子进程带有主进程的数据副本，使用子进程而不是线程，可以避免锁的情况，保证了数据安全性。

但是有个问题，子进程在进行AOF重写期间，主进程还有可能继续执行命令，导致当前数据库的数据和重写后的AOF文件中的数据不一致。这里需要引入一个AOF重写缓存，关于这一块的知识点，大家可以参考这篇大牛的博客，写的很详细：https://blog.csdn.net/hezhiqiang1314/article/details/69396887.

另外，根据讲解，我画了一张示意图描述整个AOF的执行过程，包含重写：

如何触发AOF的重写机制呢？

• 配置触发，在redis.conf中配置。# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以 启动时aof文件大小为准 auto-aof-rewrite-percentage 100 # 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化 auto-aof-rewrite-min-size 64mb
• 执行bgrewriteaof命令。

如何实现混合持久化

混合持久化，顾名思义就是同时使用AOF和RDB。如果把混合持久化打开，AOF重写的时候就直接把 RDB 的内容写到 AOF文件开头。

开启混合持久化的命令：aof-use-rdb-preamble yes

AOF的文件载入以及实现数据的还原

之前也说了，AOF文件里面保存着重建数据库状态所需要的所有写命令，所以服务器重新启动时只需要重新的载入读取AOF文件，执行一遍新建命令即可。

详细步骤如下：

• 1、创建一个不带网络连接的伪客户端（fake client）：因为Redis的命令只能在客户端上下文中执行，而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样
• 2、从AOF文件中分析并读取出一条写命令
• 3、使用伪客户端执行被读出的写命令
• 4、一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止 当完成以上步骤之后，AOF文件所保存的数据库状态就会被完整地还原出来

RDB与AOF对比

• RDB存储的某个时刻的数据快照，采用的二进制压缩存储，占用空间相对较少；AOF存储操作命令，采用文本的存储，占用空间相对较多。
• RDB由于是隔一段时间保存一次，因此性能较高；AOF因为需要保存执行过程，性能较低。
• RDB在保存时可能后丢失最后一次快照以后更改的所有数据；AOF设置为每秒保存一次，最多也就丢失2秒的数据。
• Redis以主服务器模式运行，RDB不会保存过期键值对数据，Redis以从服务器模式运行，RDB会保存过期键值对，当主服务器向从服务器同步时，再清空过期键值对；AOF写入文件时，对过期的key会追加一条del命令，当执行AOF重写时，会忽略过期key和del命令。