在上一篇Redis高级篇-1 Redis持久化-RDB演示及原理介绍**，我们Redis持久化方式一：RDB持久化。也知道了，RDB因为时间间隔时间不好控制，可能导致在时间间隔区间时候，宕机导致数据丢失了。那么有没有办法呢？我们本篇就来讲讲另一种持久化方案：AOF**

AOF原理

AOF全称：Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件中，可以看做是命令的日志文件。

AOF演示

AOF文件格式如下图：

其中的$3表示当前长度是3。当Redis异常宕机之后，重启完成，会把AOF文件中的命令在执行一遍。

AOF配置

AOF默认是关闭的，需要手动开启的。开启方式：修改redis.conf配置文件来开启AOF。修改如下：

是否开启AOF功能，默认是no

appendonly yes

AOF文件的名称

appendfilename "appendonly.aof"

AOF的命令记录的频率也是可以通过修改配置文件来配置的。我们修改redis.conf文件：

表示每执行一次写命令，立即记录到AOF文件

appendfsync always

写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案

appendfsync everysec

写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

appendfsync no

AOF频率的三种策略对比：

实战：

根据上面理论知识，我们修改对应的配置文件，然后执行一个set命令，看看是否会生成appendonly.aof文件

执行后，在查看当前目录，确实多出了一个appendonly.aof文件。这个文件的内容呢？我们查看下：

将Redis停掉，注意查看redis server的日志：

我们可以看到，calling fsync() on the AOF file.输出。说明，AOF在停机的时候，也会被执行。

我们重启Redis，查看刚才执行的set命令是否被持久化了。重启的时候，注意redis server的日志。可以看到如下图日志：

重启后，执行get命令，发现还是可以获取到数据。说明，AOF确实把数据持久化了。

我们再次执行，set num 将123 修改成 666.执行完成之后，查看aof文件。会看到如下图的：

我们从aof文件中，可以看到 set num 有两条。这说明了，aof只是记录命令，不管命令内容。只要有命令，就append到文件中。这样会导致aof文件很大的。相比起rdb的文件来说，大很多。

我们知道，刚才我们是将num由123修改成了666，其实原来的123，已经不要了。但是，aof还是记录了，那么怎么解决aof文件大的问题呢？那就需要重写aof文件。

AOF文件重写

因为AOF是记录的命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但是，只有最后一次写操作才是有意义的，之前的写操作数据被覆盖了。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果，从而来减少AOF文件体积大大小。

重写效果示意图：

执行bgrewirteaof命令：

执行后，我们在来看看aof文件：

文件内容看不懂了，这是因为，对文件进行压缩及命令优化后导致的。但是我们还是可以看到几个认识的。

什么时候执行aof文件重写？

Redis也会在触发阀值的时候自动重写AOF文件的。阀值也可以在redis.conf文件中配置。配置如下：

配置文件：

AOF和RDB两种持久化方案优缺点对比

RDB和AOF各有各的优缺点，如果对数据安全性要求较高的，在实际开发中往往会结合两者来使用。

下面我们就来对AOF和RDB两种持久化方案进行对比：

原文链接https://baijiahao.baidu.com/s?id=1763858330943737708&wfr=spider&for=pc