一.特点
Append only file,采用追加的方式保存,默认文件appendonly.aof;
记录所有的写操作命令,在服务启动的时候使用这些命令就可以还原数据库;
AOF默认关闭,需要在配置文件中手动开启。


二.写入机制
说明:AOF机制,添加了一个内存缓冲区(buffer)。
(1)将内容写入缓冲区
(2)当缓冲区被填满、或者用户手动执行fsync、或者系统根据指定的写入磁盘策略自动调用fdatasync命令,才将缓冲区里的内容真正写入磁盘里。
(3)在缓冲区里的内容未写入磁盘之前,可能会丢失。
三.写入磁盘的策略
appendfsync选项,这个选项的值可以是always、everysec或者no

**always:**服务器每写入一个命令,就调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据
everysec(默认):服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据
**No:**服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的
运行速度:always的速度慢,everysec和no都很快
四.aof重写机制
AOF文件过大,合并重复的操作,AOF会使用尽可能少的命令来记录。
1.重写过程
(1)folk一个子进程负责重写AOF文件
(2)子进程会创建一个临时文件写入AOF信息
(3)父进程会开辟一个内存缓冲区接收新的写命令
(4)子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写操作由子进程写入到临时文件中
(5)新文件替代旧文件
重写的本质:就是将操作同一个键的命令,合并。从而减小AOF文件的体积

2.aof重写触发机制
(1)手动:
客户端向服务器发送BGREWRITEAOF命令
(2)自动:
配置文件中的选项,自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size ,
触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size时,才会考虑是否需要进行AOF重写,这个选项用于避免对体积过小的AOF文件进行重写
auto-aof-rewrite-percentage
指定触发重写所需的AOF文件体积百分比:当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积,并且超过上一次重写之后的AOF文件体积的percent %时,就会触发AOF重写。(如果服务器刚刚启动不久,还没有进行过AOF重写,那么使用服务器启动时载入的AOF文件的体积来作为基准值)。将这个值设置为0表示关闭自动AOF重写。
五.优点
写入机制,默认fysnc(手工同步)每秒执行,性能很好不阻塞服务,最多丢失一秒的数据;
重写机制,优化AOF文件;
如果误操作了(flushall等),只要AOF未被重写,停止服务移除AOF文件尾部FLUSHALL命令,重启Redis,可以将数据集恢复到FLUSHALL 执行之前的状态。
六.缺点
相同数据集,AOF文件体积较RDB大了很多;
恢复数据库速度较RDB慢(文本,命令重演)。
本文深入解析了Redis的AppendOnly File (AOF)持久化机制,包括写入策略(always、everysec、no)、AOF重写规则、性能与恢复特性。重点讲解了AOF的优点如高可用和数据恢复,以及缺点如文件体积大和恢复速度慢。
163

被折叠的 条评论
为什么被折叠?



