本文详细介绍了Redis的AOF（Append Only File）持久化机制，包括其工作原理、启动方式、文件修复、重写规则及优缺点。AOF通过记录所有写操作日志确保数据完整性，但在文件大小和恢复速度上与RDB（快照）存在差异。Redis重启时优先使用AOF恢复数据，而RDB更适合用于备份和快速重启。在实际应用中，可以根据性能需求调整AOF的配置，如开启AOF的同时保留RDB备份，或者关闭AOF以减少IO操作。
目录
AOF(Append Only File)
AOF的工作原理
以日志的形式记录每一个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。也就是说，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF的启动
aof默认是不开启的，需要手动配置。在conf文件中把appendonly改为yes即可，然后需要重启redis服务端方能生效
AOF的修复
注意如果aof文件有错误，redis是无法启动的，我们需要修改aof文件==》使用redis提供的工具redis-check-aof-fix
修复命令如下：
redis-check-aof --fix appendonly.aof
AOF重写的规则
aof默认是文件无限追加，文件会越来越大，如果aof文件大于64m，redis就会fork一个新的进程来将我们的文件进行重写
AOF的优缺点
优点：当设置为always时，每次写操作都会同步，文件完整性会非常好。当设置erverysec时，每秒执行一次同步，可能丢失的数据为1s，当设置为no时，不会自动执行同步，交给操作系统自己来同步，速度是最快的。
缺点：aof的文件大小远远大于rdb，修复的速度也比rdb慢。aof的运行效率比rdb慢，所以redis默认配置未rdb持久化
appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof" # 持久化的文件的名字
# appendfsync always # 每次修改都会 sync。消耗性能
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！
# rewrite 重写
总结Redis的持久化
1.RDB持久化方式能够在指定时间间隔内对数据进行快照存储
2.AOF持久化方式记录每次对服务器写的操作，当服务器重启时会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作末尾，Redis还能对AOF文件进行后台重写，使得AOF文件体积不至于过大。
3.如果只做缓存，也就是只希望数据在服务器运行时存在，那完全可以不考虑持久化
4.当同时开启RDB和AOF
- redis重启时会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集完整
- 如果使用AOF建议不要关闭RDB，因为RDB更适合备份数据库(AOF在不断变化不好备份)，快速重启，留着RDB可以放到集群的从机上，以防万一
5.性能建议
- 一般来说，RDB使用默认15分钟备份一次即可，只保留save 900 1 这条规则
- 如果开启AOF，好处是恶劣环境下丢失的数据量在2秒内，代价是带来了持续的IO操作。此外，AOF重写的大小是64M，可以改成5G以上，防止重写后的数据不停累加，不停重写，造成阻塞。
- 开启AOF，把aopendonly设置为no，只靠主从复制实现高可用也可以，这样能省掉一大笔IO，也能减少重写时系统波动。代价是如果主从同时宕机，会丢失十几分钟的数据。启动脚本时需要比较主从中各自的RDB文件，载入较新的一个。微博采用这种架构
扫一扫
4767
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
