Redis 有两种持久化方式：AOF 和 RDB。本节就先来聊聊 AOF。

AOF（Append Only File） 日志是写后日志，Redis 会先执行命令，把数据写入内存，然后才记录日志。

1 开启 AOF 日志

在 Redis 的配置文件中，设置以下两个参数即可开启 AOF：

appendonly yes
appendfilename "appendonly.aof"

appendonly：表示是否开启 AOF appendfilename：定义 AOF 文件名

2 AOF 的内容

AOF 里记录的是 Redis 收到的每一条写命令，这些命令是以文本形式保存的。我们就来通过一个实验看下 AOF 中的内容。首先连上本地 Redis（本节的版本为：5.0.7）：

redis-cli -p 6301

执行

set aa 1

然后查看 AOF 文件的最后几行内容：

tail  /data/redis6301/data/appendonly.aof

如上图，其中 *3 表示当前命令有三个部分，每个部分从 $“数字”开始，数字表示这部分中命令、键或者值一同有多少字节。

3 为什么是 AOF 而不是 WAL

很多数据库都是采用的 Write Ahead Log（WAL）方式，其特点就是先把修改的数据记录到日志中，再进行写数据的提交，可以方便通过日志进行数据恢复。

但是 Redis 采用的却是 AOF，特点就是先执行写命令，把数据写入内存中，再记录日志。

那么 Redis 为什么考虑使用 AOF 而不是 WAL 呢？

这是因为先让系统执行命令，只有命令能执行成功，才会被记录到日志中。因此，Redis 使用写后日志这种形式，可以避免出现记录错误命令的情况。

另外还有一个原因就是：AOF 是在命令执行后才记录日志，所以不会阻塞当前的写操作。

4 AOF 文件同步策略

AOF 虽然避免了对当前命令的阻塞，但是可能阻塞下一个操作，这是因为 ，AOF 日志是在主线程中执行的，如果写日志时磁盘 IO 压力较大，就会导致后续的写操作很慢，从而导致命令阻塞。

那么 Redis 有没有类似 MySQL 中控制 redo log 落盘时机的参数呢？

有意思的是的确有类似参数 appendfsync，控制 AOF 缓冲区文件同步策略。该参数的可配置值如下：

具体怎么配置，建议如下：

• 如果对性能要求很高，而对数据可靠性要求不高，就选择 No 策略；
• 如果想要得到高可靠性保证，就选择 Always 策略；
• 如果允许数据有一点丢失，又希望性能别受太大影响的话，那么就选择 Everysec 策略。

5 AOF 重写机制

如果实例运行比较久，并且修改比较频繁，那么 Redis 的 AOF 文件很可能比较大，那怎么解决呢？

Redis 引入了 AOF 重写机制。

AOF 重写机制是把 Redis 进程内的数据转化为写命令同步到新的 AOF 文件中。并且重写的 AOF 文件可以变小，原因如下面几点：

• 旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。
• 已经过期的 key 不再写入新的 AOF 文件中。

什么时候会触发 AOF 重写机制呢？

首先可以直接执行 bgrewriteaof 命令触发重写机制。

而自动触发涉及到几个参数

首先在 Redis 中执行

info persistence

其中：

• aof_current_size：表示当前 AOF 文件空间
• aof_base_size：表示上一次重写后 AOF 文件空间

而在配置文件中，AOF 重写涉及到以下两个参数：

• auto-aof-rewrite-min-size: 表示运行 AOF 重写时文件的最小体积，默认为64MB
• auto-aof-rewrite-percentage: 表示当前 AOF 重写时文件空间（aof_current_size）超过上一次重写后 AOF 文件空间（aof_base_size）的比值多少后会重写。

同时满足下面两个条件，则触发 AOF 重写机制：

• aof_current_size 大于 auto-aof-rewrite-min-size
• 当前 AOF 相比上一次 AOF 的增长率:(aof_current_size - aof_base_size) / aof_base_size 大于或等于 auto-aof-rewrite-percentage