😄作者简介： 小曾同学.com,一个致力于测试开发的博主⛽️，主要职责：测试开发、CI/CD
如果文章知识点有错误的地方，还请大家指正，让我们一起学习，一起进步。
😊 座右铭：不想当开发的测试，不是一个好测试✌️。
如果感觉博主的文章还不错的话，还请点赞、收藏哦！👍

一 前言 ❤️

Redis 持久化主要解决数据丢失问题，在Redis中有两种持久化方式：

• RDB 持久化 【文章精选】
• AOF 持久化【本篇主要内容】

二 AOF 详解🌟

AOF 全称 Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
AOF 默认是关闭的，需要修改 redis.conf 配置文件来开启AOF，具体开启如下方式：
（Mac 中redis.conf 的路径为：/usr/local/etc/redis.conf

# 是否开启AOF功能，默认是no
appendonly yes
#AOF文件的名称
appendfilename "appendonly.aof"

#AOF的命令记录的频繁也可以通过redis.conf文件来配置
# 表示每执行一次写命令，立即记录到AOF文件 (安全性高，性能差)
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
appendfsync no

上述三种命令写入的优缺点

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

完成上述配置后，我们要重启 redis，然后客户端连接写入数据，set num 12345 ，我们会看到在 /usr/local/var/db/redis 目录下会生成一个 appendonly.aof文件，查看内容 cat appendonly.aof，能够看到我们刚刚的操作，

此时如果停止 Redis，我们会看到还会进行一次 Calling fsync() on the AOF file AOF检查，此时再开启Redis，会看到 DB loaded from append only file: 0.001 seconds，数据从aof文件中恢复。

AOF 因为是记录命令，所以 AOF文件会比RDB文件大很多，而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行 bgrewriteaof 命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。（当set num 多次时，只保留最后一次命令）

127.0.0.1:6379> set num 12345
OK
127.0.0.1:6379> set name zeng
OK
127.0.0.1:6379>
127.0.0.1:6379> keys *
1) "name"
2) "num"
127.0.0.1:6379> set num 999
OK
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6379>

Redis也会在触发阈值时自动去重写AOF文件，阈值也可以在redis.conf中配置

#AOF文件比上次文件，增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100 # 默认值
#AOF 文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb # 默认值

三 RDB与AOF 优缺点✨

之前分享过RDB持久化相关内容，可以参考这篇文章，两者优缺点具体如下：

	AOF	RDB
持久化方式	记录每一次执行的命令	定时对每个内存做快照
数据完整性	相对完整，取决于刷盘策略	不完整，两次备份之间会丢失
文件大小	记录命令，文件体积很大	会有压缩，体积小
数据恢复优先级	高，因为数据完整性更高	低，不如AOF
宕机恢复速度	慢	很快
系统资源占用	低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源	高，大量CPU和内存消耗
使用场景	对数据安全性要求较高	可容忍数分钟的数据丢失，最求更快的启动速度