上一篇中，我们说了Redis持久化中的RDB。今天，我们详细学习一下AOF持久化机制的实战。

一、如何配置AOF持久化机制

默认情况下，redis是不开启AOF持久化的。我们需要手动将配置文件中的appendonly改成yes，表示开启AOF持久化机制。在生产环境中，一般来说都会开启AOF，除非是说随便丢个几分钟的数据也无所谓。

打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache，然后每隔一定时间再fsync一下。而且即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的，因为aof数据比较完整。

对于AOF的fsync策略，有三种策略可以选择：

（1）always：每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了。

（2）everysec： 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的。（默认）

（3）no：仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了。

二、实战

1、验证AOF持久化已经在起作用了。

（1）我们先删除dump.rdb和appendonly.aof文件。写入k1，然后通过kill -9杀死进程。

（2）可以看到重新生成了appendonly.aof文件，此时我们重启redis服务，看k1的值是否被持久化。（可以看到k1的值被持久化，而该值就是从AOF文件恢复回来的。）

2、验证redis启动时，是从AOF文件恢复持久化数据，而非dump.rdb。

（1）我们在设置一个k2的值，然后通过redis-cli SHUTDOWN停掉redis进程。

（2）重启redis服务，此时dump.rdb和appendonly.aof都记录了k2的值，无法看出redis重启是否是从aof中恢复的。那么我们再写入k3，然后通过kill -9杀死redis进程。（我们知道用kill方式杀死进程，持久化数据是不会被写进dump.rdb中的）

（3）重启redis服务，看下k3是否被持久化，若被持久化，则可验证redis启动时，从aof文件中恢复数据。