持久化-AOF

原创于 2025-08-12 06:30:00 发布 · 903 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#java #spring #spring boot #redis #面经 #面试 #rag

面经实战之redis 专栏收录该内容

6 篇文章

订阅专栏

文章目录

AOF是什么
AOF配置
AOF优点
总结
如何选择
性能建议

AOF是什么

AOF（Append Only File）是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF配置

AOF配置【APPEND ONLY MODE】
appendonly no  						# 默认no
appendfilename "appendonly.aof" 	# 文件名
appendfsync [always/everysec/no]
  always		同步持久化，redis每次发生数据改变都会被立即记录到磁盘，性能较差但数据完整性最好
  everysec		默认推荐，异步操作，每秒记录一次，最多损失1s的数据
  no			不进行持久化
no-appendfsync-on-rewrite no 	# 重写时是否运用appendfsync，默认no即可，保证数据安全性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF优点：
  每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
  每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
  不同步：appendfsync no 从不同步
  
AOF缺点：
	1、文件大、恢复慢：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
    2、Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

rewrite

是什么：

AOF采用文件追加方式，文件会越来越大。为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似.

触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb 【一般3GB起步】

redis默认使用AOF恢复数据，因为aof保存的数据更全面

AOF优点

每修改同步：appendfsync always 同步持久化每次发生数据变更会被立即记录到磁盘性能较差但数据完整性比较好
每秒同步：appendfsync everysec 异步操作，每秒记录如果一秒内宕机，有数据丢失
不同步：appendfsync no 从不同步

AOF缺点：

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

总结

AOF文件时一个只进行追加的日志文件
Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松
对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
根据所使用的fsync 策略，AOF的速度可能会慢于RDB

如何选择

1、 RDB持久化方式能够在指定的时间间隔内对数据进行快照存储，AOF持久化方式记录每次对服务器的写操作，当服务器重启时会重新执行这些命令来恢复原始数据，Redis还会对AOF文件进行重写，避免文件体积过大。

2、建议同时开启RDB、AOF持久化方式：redis会优先载入aof文件来恢复原始数据，因为通常情况下aof文件保存的数据集比rdb文件保存的数据集要完整。但是也不建议只用AOF，因为RDB更适合备份数据库了，而AOF数据不断变化，不好备份。

3、只做缓存：可以都不使用RDB、AOF

性能建议

因为RDB文件只做后备用途，建议只在slave上持久化RDB，而且重要15分钟备份一次就够了【只保留save 900 1】
如果启用AOF，好处是在最坏情况下也只会丢失1s数据，启动脚本简单加载自己的aof文件就可以恢复，代价一是带来了持续的IO，二是rewrite的最后将rewrite过程中产生的新数据写到新文件会造成不可避免的阻塞，应当尽量减少rewrite的频率，建议auto-aof-rewrite-min-size 设置为5G，默认超过原来的100%进行重写。
如果不启用AOF，仅靠master-slave Replication实现高可用也可以，能节省一大笔IO、以及重写rewrite带来的系统波动，代价是如果master/slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个master/slave的RDB文件。