Append-only File(AOF)Redis每次接收到一条改变数据的命令时,它将把该命令写到一个AOF文件中(只记录写操作,不记录读操作),当Redis重启时,它通过执行AOF文件中所有的命令来恢复数据。
AOF是在RDB之后出现的一种技术,这种方式的持久化让redis的数据不会丢失;
当使用Redis存储非临时数据时,一般需要开启AOF持久化来降低Redis故障导致的数据丢失,AOF可以将Redis执行的每一条写命令追加到硬盘文件中,这一过程会降低Redis的性能,但大部分情况下这个影响是能够接受的,另外使用较快的硬盘(固态硬盘)可以提高AOF的性能;
AOF方式的数据持久化,仅需在redis.conf文件中配置即可,搜索APPEND ONLY MODE;
配置文件 appendonly no 默认是no,改成yes即开启aof持久化;
2.AOF的相关配置选项
appendonly
默认是no,改成yes即开启了aof持久化;
appendfilename
指定AOF文件名,默认文件名为appendonly.aof;(该文件要Redis自己启动创建,测试发现我们自己创建该文件,无法向文件写入持久化命令)
appendfsync
配置向aof文件写命令数据的策略:
no:不主动进行同步操作,而是完全交由操作系统来做(即每30秒一次),比较快但不是很安全;
always:每次执行写入都会执行同步,慢一些但是比较安全
everysec:每秒执行一次同步操作,比较平衡,介于速度和安全之间
dir
指定AOF和RDB文件的目录
auto-aof-rewrite-percentage
当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写,如果之前没有重写,则以启动时的aof文件大小为依据
auto-aof-rewrite-min-size
允许重写的最小AOF文件大小;
最后,我们可以同时使用这两种方式,redis默认优先加载aof文件;
重写是什么回事:
AOF 文件会在操作过程中变得越来越大。比如,如果你做一百次加法计算,最后你只会在数据库里面得到最终的数值(k 100),但是在你的 AOF 里面会存在 100 次记录,其中 99 条记录对最终的结果是无用的;但 Redis 支持在不影响服务的前提下在后台重构 AOF 文件,让文件得以整理变小;
3.AOF的重写原理
重写时,主进程会fork一个子进程出来进行AOF重写,这个重写过程并不是基于原有的aof文件来做的,而是有点类似于快照的方式,全量遍历内存中的所有数据,然后逐个序列到aof文件中。
在fork子进程这个过程中,服务端仍然可以对外提供服务,在重写aof文件的过程中,主进程的数据更新操作,会缓存到aof_rewrite_buf中,也就是单独开辟一块缓存来存储重写期间收到的操作命令,当子进程重写完以后再把缓存中的数据追加到新的aof文件。
当所有的数据全部追加到新的aof文件中后,把新的aof文件重命名,此后所有的操作都会被写入新的aof文件。如果在rewrite过程中出现故障,不会影响原来aof文件的正常工作,只有当rewrite完成后才会切换覆盖原来那个文件,因此这个 rewrite过程是比较稳定可靠的;