进阶Redis系列(十一)：超全详解Redis持久化机制AOF（代码示例）【面试必问/工作常用】

学习Redis之前，我还是觉得我务必跟你说一声，也是在我文章之中说的很多的一句话，我想也会适用于学习Redis，那就是在接触文章里的Reids命令时，不用试图去记这些命令 ，用到时去看API帮助文档即可;会用了或者实践过了再去了解也不会迟。

上手Redis系列

上手Redis必知必会：最基础知识点和最基本常用操作

上手Redis系列(一)：超全String字符串类型详解
上手Redis系列(二)：超全List列表类型详解（代码图文示例）
上手Redis系列(三)：超全集合Set类型详解（代码图文示例）
上手Redis系列(四)：超全哈希Hash类型详解（代码图文示例）
上手Redis系列(五)：超全有序集合Zset类型详解
上手Redis系列(六)：超全Geospatial特殊类型详解(地理位置)
上手Redis系列(七)：超全HyperLogLog特殊类型详解
上手Redis系列(八)：Bitmaps特殊类型详解
上手Redis系列(九)：事务操作
进阶Redis系列(十)：超全详解Redis持久化机制RDB
进阶Redis系列(十一)：超全详解Redis持久化机制AOF

Redis持久化机制中有两种，第一种是在进阶Redis系列十中详解的RDB，还有的第二种就是接下来要讲的AOF持久化机制。

一、什么是AOF持久化机制

AOF (append only file) 以日志的方式记录每一次写操作（读操作不记录）,不改写文件只追加文件，启动redis时会读取该文件重新构建数据，redis如果重启就根据日志从先往后执行完数据的恢复工作。

简单的理解：

AOF用日志的方式记录每次写操作，恢复的时候把文件全部执行一遍即可。

跟进阶Redis系列十详解Redis持久化机制RDB(没看的小伙伴，建议看看，Redis的持久化方式不多，就这个两个)中不同的是AOF不是默认的，而是需要在redis.conf中配置的。

但是相同的是AOF持久化机制也是生成一个文件，appendonly.aof 用于存储命令。

二、AOF的持久策略

AOF的持久化默认是秒同步，所以AOF比RDB要慢，但是AOF关闭同步fsync，速度就是一样的了。

appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

appendfsync no:不同步。

在redis.conf可以看到，也可以做相应的配置选择持久化策略。

三、AOF的重写机制

在AOF持久化机制中，AOF文件就是默认一直追加的，文件会越来越大可能会导致AOF文件过于庞大。所以为了避免出现这种情况，Redis使用了重写机制，一旦AOF文件超过指定的阈值时自动启用AOF文件的内容压缩，然后保留可恢复的最小数据集。

看图，会更加直观。

AOF的重写触发机制：Redis会记录上一次重写时的AOF文件大小，默认配置是当AOF文件大小是上一次一倍且大于64mb就会触发重写机制。

四、AOF开启和拆开AOF文件

4.1详解如何开启AOF

redis中AOF默认是不开启，开启AOF功能需要配置redis.conf中的appendonly no改为yes。

我们依然来修改redis.conf文件。

改好之后，需要关闭我们的Redis

SHUTDOWN

然后再次重启。

redis-server

会发现已经触发AOF持久化机制，生成了appendonly.aof文件。

4.2拆开AOF文件

我们往Redis中添加数据，来看看AOF持久化机制在aof文件存储命令的呈现是怎么的？

不知道你好不好奇？

反正我挺好奇滴！

vim appendonlay.aof

可以看到我们 写的命令 都记录在这里！

五、如何修复被破坏的AOF文件

我们拆开了aof文件来看，那么如果修改了aof文件会怎么样呢？

毫无疑问会破坏我们到存储写操作命令的appendonlay.aof文件。

可以来折腾一下，嘿嘿。

我们上面已经添加了三个值。

接下来 SHUTDOWN 退出 Redis

我们在appendonlay.aof里随便乱添加几个字母，然后保存。

再次开启Redis。

会发现连接被拒绝。

可以发现 一旦破坏了appendonlay.aof文件，断开后的Redis就不能再连接了。

那怎么办呢？

放心，放心

可以使用redis的redis-check-aof修复

edis-check-aof

aof一旦有错，redis是启动不了的，所以我们需要修复这个文件。

redis-check-aof --fix appendonly.aof 修复appendonly.aof文件

redis-check-aof 修复后，再次打开appendonly.aof文件，可以看到没有了之前我们乱输入的字母

修复成功后，我们再次连接redis。

发现一旦appendonly.aof修复成功，没有错误，就可以连接上redis了。

细心的小伙伴可能会发现，修复的数据是乎有差错，少了数据。

对的，修复时是会有一定的数据丢失的,

但是，但是…千万

不要因为小恶而忘记大善。

AOF的优势，且听我娓娓道来。

六、AOF优势和劣势

优势：

1. AOF文件存储了所有写入操作（每次修改都会同步，让文件的完整性更好）。
2. 可以更好的保护数据不丢失，所以每秒同步，但是可能会丢失一秒数据。
3. AOF文件变大时Redis可以后台自动对AOF重写且重写安全。
4. AOF有多种持久化策略选择，其中有：每修改同步、每秒同步、不同步。

劣势：

1. 对于相同数据文件，AOF远比RDB大，所以修复速度也比RDB慢。
2. AOF的速度比RDB慢，但一旦关闭fsync速度会跟RDB一样。

七、最后

最后的最后，为了更好的阅读体验，我把想说的话都放在了下面，嘿嘿。

我是一颗剽悍的种子 把我会的，认真的分享 是我写博客一直不变的信条。
如果你能看到这篇博文，说明咱们还是很有缘的；希望能带给你一些许帮助，创作的不易， 把我文章的知识带走，你的三连留下，点赞，评论，关注，是我最大的动力。