Redis入门之浅谈aof持久化机制

首先，aof是redis的一种记录数据库写操作的持久化方案，他会忠实的记录所有的写操作，并且以redis协议的格式存储在一个.aof文件中，在重启redis的时候，redis可以根据.aof文件的内容来恢复数据集。

举个例子：首先，我们启动redis服务，并且存储一些数据，这里我随便存储了四条数据，如下图所示：



然后我们将所有的数据清除，使用命令flushall：



这样，可以看到现在已经没有任何数据了，这样，我们就可以尝试使用aof来回复这些数据，现在shutdown+exit关闭redis，查看usr/local/bin目录（linux的默认安装路径，我的redis就是安装在这个路径上面的）可以发现多出来一个appenonly.aof文件，很显然这个文件就是用来记录数据库写操作的aof文件，我们就是通过这个文件来回复数据的，这里要注意的是，由于执行了shutdown命令，redis的rdb也会启动持久化操作，所以生成了dunp.rdb文件，为了避免rdb起到回复数据的作用，我们这里使用rm
-f filename命令手动删除这个文件 。



好了，现在按道理来说，再次打开redis是可以看到恢复了的数据的，那么到底能不能恢复呢，我们在次启动redis然后keys *看一看:



你会发现，怎么什么都没有，难道aof不好使吗，当然不是得了，那是因为aof机制忠实的记录了每一条写操作，包括你输入的flushall，因此，在aof文件中，你的flushall命令也会记录进去，可以使用vim appendonly.aof命令查看一下aof文件，可以发现最后一条记录就是flushall，这里我们手动删除它（实际情况中不建议手动修改.aof文件，事实上也没有人回去执行flushall命令），然后我们退出redis，然后再次启动，会发现数据已经给你恢复成功了：



这里面需要注意的是：

1. 首先，redis默认是关闭aof的，我们需要修改配置文件（.redis.conf），如果只是学习目的，建议另外复制一份配置文件来修改，在使用redis的时候直接启动这个复制的配置文件，打开配置文件可以看到：



下面有一个appendonly的参数，起默认值是no，就是关闭aof，我们把他的值设置为yes，然后wq保存退出；

2. 在上面的配置文件中，在appendonly参数的下一行（截图没显示）是配置aof文件的默认名，默认名字就是appendonly.aof，这里建议不要修改。

接着我们在看配置文件，其中显示了aof的三种持久化策略：



其中always是同步持久化，意思就是只要有操作我就记录，这种策略可以使数据集有较好的完整性，但是性能方面比较差

everysec是默认的策略，没秒内有变化我就记录

组后一个no是不记录。

3. aof文件损坏了怎么办？如果一个aof文件内容存在不合法的语句或者其他损坏情况，那么redis是不会正常启动的，因为redis启动的时候会首先默认加载aof文件，我们可以手动模拟一下：首先，我在aof文件中随便输入一些内容：



这个时候，我们再次启动redis，会发现服务启动不了：



那么怎么办呢，难道我们的数据就不要了吗，当然不是，redis有一个恢复文件的办法，我们可以使用redis-check-aof --fix appendonly.aof命令修复.aof文件，这个命令会将.aof文件中的不合法语句删除，我们执行之后就会发现又可以正常启动redis了，并且之前的数据都在：



看到了，可以成功启动redis，并且之前存储的四条记录都在。

4. 再有一点就是redis中rdb与aof是可以同时使用的，但是默认首先加载aof文件。

5. 将有数据的aof文件复制一份保存到对应的目录（config get dir）

最后，需要说明的是AOF采用文件追加的方式，文件会越来越大，为了避免这种情况，redis拥有重写机制，当AOF文件大的大小超过了所设定的阈值的时候，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，使用命令bgrewriteaof，这种重写的内部机制是，redis会记录上次重写的时候AOF文件的大小，默认配置是当AOF文件大小是上次重写之后大小的一倍并且文件大于64M的时候触发（可以参见配置文件）。

相对于rdb的劣势：

1. 对于相同的数据集来说，aof文件的体积远大rdb文件的体积

2. 根据所使用的fsynccelve，aof的速度慢于rdb

aof与rdb的选择：

官方推荐同时使用两种持久化方式