Redis之AOF持久化

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！

appendonly yes

另外几个和AOF相关的属性如下：

appendfilename “appendonly.aof”

appendfsync always

appendfsync everysec

appendfsync no

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

这几个属性的含义分别如下：

1.appendfilename表示生成的AOF备份文件的文件名。

2.appendfsync表示备份的时机，always表示每执行一个命令就备份一次，everysec表示每秒备份一次，no表示将备份时机交给操作系统。

3.no-appendfsync-on-rewrite表示在对aof文件进行压缩时，是否执行同步操作。

4.最后两行配置表示AOF文件的压缩时机，这个我们一会再细说。

同时为了避免快照备份的影响，我们将快照备份关闭，关闭方式如下：

save “”

save 900 1

save 300 10

save 60 10000

此时，当我们在redis中进行数据操作时，就会自动生成AOF的配置文件appendonly.aof，如下：

注意此时没有dump.rdb文件，这时我们将redis关闭并重启，会发现之前的数据都还在，这就是AOF备份的结果。

AOF备份的几个关键点

1.通过上面的介绍，小伙伴们了解到appendfsync的取值一共有三种，我们在项目中首选everysec，always选项会严重降低redis性能。

2.使用everysec，最坏的情况下我们可能丢失1秒的数据。

AOF文件的重写与压缩

AOF备份有很多明显的优势，当然也有劣势，那就是文件大小。随着系统的运行，AOF的文件会越来越大，甚至把整个电脑的硬盘填满，AOF文件的重写与压缩机制可以在一定程度上缓解这个问题。

当AOF的备份文件过大时，我们可以向redis发送一条bgrewriteaof命令进行文件重写，如下：

127.0.0.1:6379> BGREWRITEAOF

Background append only file rewriting started

(0.71s)

bgrewriteaof的执行原理和我们上文说的bgsave的原理一致，这里我就不再赘述，因此bgsave执行过程中存在的问题在这里也一样存在。

bgrewriteaof也可以自动执行，自动执行时间则依赖于auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置，auto-aof-rewrite-percentage 100表示当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，如果之前没有重写，则以启动时的aof文件大小为依据，同时还要求AOF文件的大小至少要大于64M(auto-aof-rewrite-min-size 64mb)。

最佳实践

---

总结

这份面试题几乎包含了他在一年内遇到的所有面试题以及答案，甚至包括面试中的细节对话以及语录，可谓是细节到极致，甚至简历优化和怎么投简历更容易得到面试机会也包括在内！也包括教你怎么去获得一些大厂，比如阿里，腾讯的内推名额！

某位名人说过成功是靠99%的汗水和1%的机遇得到的，而你想获得那1%的机遇你首先就得付出99%的汗水！你只有朝着你的目标一步一步坚持不懈的走下去你才能有机会获得成功！

成功只会留给那些有准备的人！

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
片转存中…(img-Jio5OSMu-1714649320251)]

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！