英文名称是 Append Only File。同样地，它也有一个常用的名字：文件追加持久化。与RDB 不同的是，它是通过保存所执行的写命令来实现的，并且保存的数据格式是客户端发送的命令。
想要使用 AOF 持久化方式，需要启用配置文件中的 appendonly 参数。默认情况下，Redis 是不开启的。
开启 AOF 持久化后每执行一条修改数据的命令，Redis 就会将该命令写入 aof_buf 缓冲区。后续写入 AOF 文件中的操作是由下面的配置来控制的：
这三个配置项分别表示：
appendfsync always：每次写入都进行刷盘操作，对性能影响最大，占用磁盘 IO 较高，数据安全性最高。
appendfsync everysec：1秒刷一次盘，对性能影响相对较小。
appendfsync no：按照操作系统的机制进行刷盘，对性能影响最小，数据安全性低。
3、AOF 重写机制随着命令的不断写入，AOF 文件会变得越来越大，这时候该如何是好呢？别急，Redis 中提供了瘦身功能，也就是重写机制。
Redis 配置文件中有两个对应的参数是来决定重写机制的触发时机的。
auto-aof-rewrite-percentage：AOF 文件距离上次文件增长超过多少百分比
auto-aof-rewrite-min-size：AOF 文件体积最小多大以上触发
满足所设置的条件时，会自动触发 AOF 重写，此时 Redis 会扫描整个实例的数据，重新生成一个 AOF 文件来达到瘦身的效果。
4、AOF 文件恢复
同样地，我们也需要对 AOF 文件进行恢复。和 RBD 不同的是，Redis 中是通过创建一个不带网络连接的伪客户端来进行实现的。为什么要创建伪客户端呢？你想想 AOF 文件中的数据格式，都是由命令组成的。通过客户端直接执行每条命令就可以将数据进行恢复。
在这里需要注意的是，如果服务器开启了 AOF 持久化功能，会优先使用 AOF 文件来进行恢复。只有在 AOF 关闭状态下，服务器才会使用 RDB 文件来进行还原。
到这里，对两种持久化也有了一定的认识，那么我们来看看它们分别有什么优点和缺点：
1、RDB 优点与缺点 （1）优点文件体积小：RDB 的文件内容是二进制格式，因此体积比实例内存小。恢复速度快：当 Redis 实例恢复时，加载 RDB 文件速度很快，能在很短时间内迅速恢复数据。
（2）缺点数据缺失：RDB 保存的是某一时刻的数据，当 Redis 实例某一时刻异常时，会导致数据丢失。消耗资源：RDB 文件的生成会消耗大量的 CPU 和内存资源，有一定代价。
2、AOF 优点与缺点 （1）优点数据更完整：AOF 中是及时写入的方式，数据保存更完整。恢复时降低数据的损失率
易读性强：AOF 中保存的数据格式是客户端的写入命令，可读性性强。
（2）缺点文件体积大：AOF 中存储客户端所有的写命令，未经压缩，随着命令的写入，文件会越来越大。增加磁盘IO：AOF 文件刷盘如果采用每秒刷一次的方式会导致磁盘IO升高，影响性能。
混合持久化既然 RDB 与 AOF 持久化都存在各自的缺点，那么有没有一种更好的持久化方式？