【Redis】持久化（下）-- AOF

文章目录

• AOF
• • 概念
  • 如何使用AOF
  • AOF工作流程
  • 命令写入演示
  • 文件同步策略
• `AOF`的重写机制
• • 概念
  • 触发重写机制
  • • `AOF`重写流程
• 启动时数据恢复
• 混合持久化
• 总结

AOF

概念

AOF持久化:以独立日志的方式记录每次的写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的.AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式.

如何使用AOF

开启AOF功能需要修改配置文件:appendonly yes,默认情况下不开启.AOF文件名通过appendfilename配置(默认是appendonly.aof)设置.保存目录同时RDB持久化方式一致,通过dir配置指定.(注意:当开启AOF的时候,RDB一般就不会生效了)

• 打开配置文件vim /etc/redis/redis.conf,将该位置修改为appendonly yes
  

• 可修改AOF文件名:
  

• 保存目录:
  

AOF工作流程

• 所有的写入命令会追加到aof_buf缓冲区中
• AOF缓冲区根据对应的策略向硬盘做同步操作
• 随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩目的
  • 重写:在最终结果一致的情况下,可以剔除命令中一些比较冗余的操作
• 当Redis服务器启动实词,可以加载AOF文件进行数据恢复

命令写入演示

• 我们在配置文件中打开AOF持久化后,当我们输入命令时,在var/lib/redis目录中自动出现了一个新的目录:appendonlydir
  
• 打开appendonlydir目录
  

-rw-r--r-- 1 root root 88 Oct  6 20:39 appendonly.aof.1.base.rdb
-rw-r--r-- 1 root root 73 Oct  6 20:39 appendonly.aof.1.incr.aof
-rw-r--r-- 1 root root 88 Oct  6 20:39 appendonly.aof.manifest

• appendonly.aof.1.base.rdb：这是 Redis AOF 文件的基础 RDB（Redis Database Backup）文件，通常用于在 AOF 恢复时提供一个初始的数据库状态。

• appendonly.aof.1.incr.aof：这是增量 AOF 文件，包含自上次 RDB 快照以来对数据库的所有写操作。它是 AOF 的核心部分。

• appendonly.aof.manifest：这是 AOF 文件的清单，包含有关 AOF 文件的元数据，如版本、文件大小等。

注意:AOF命令写入的内容直接是文本协议格式.例如:set key111 11111111111111111; 这条命令,在AOF文件中会追加如下文本:

疑问1:AOF作为一种实时备份的持久化方式,是否会影响Redis的性能呢?
答案: 不会
原因:

• AOF会先写入内存缓冲区aof_buf中,然后一次性刷入磁盘中,这样可以减少磁盘IO
• AOF在磁盘中时顺序读写,新的命令会追加到原本的文件中

疑问2:AOF过程中为什么需要aof_buf这个缓冲区?
Redis使用单线程响应命令,如果每次写AOF文件都直接同步到硬盘中,性能就会从内存的读写变成IO读写,性能必然下降.所以,先写入缓冲区中可以有效减少IO次数,同时,Redis还可以提供多种缓冲区同步策略,让用户根据自己的需求做出合理的平衡.

文件同步策略

Redis提供了多种AOF缓冲区同步文件策略,由参数appendfsync来控制.
在配置文件中:

上述的同步文件策略,数据写入磁盘的频率由高到低,性能由低到高

系统调用write和fsync说明:

• write会触发延迟写机制.Linux在内核提供页缓冲区用来提升硬盘IO性能.write操作在写入系统缓冲区后立即返回.同步硬盘操作依赖于系统调度控制,例如:缓冲区页空间写满或者达到了特定的时间周期.同步文件之前,如果此时系统故障宕机,缓冲区内数据将会丢失.(即 将内存中的数据先写入到内核的页缓冲区中,再由系统调度控制同步硬盘操作)
• Fsync针对单个文件操作,做强制硬盘同步,fsync将阻塞直到数据写入到硬盘

• 配置always时,每次写入都要同步AOF文件,性能很差,在一般的SATA硬盘上,只能支持大约几百TPS写入.除非是非常重要的数据,否则不建议配置.
• 配置为no时,由于操作系统同步策略不可控,虽然提高了性能,但是数据丢失风险大增,除非数据的重要程度很低,否则不建议配置
• 配置为svseysec,是默认配置,也是推荐配置,兼顾了数据安全性和性能.理论上最多丢失1秒的数据

AOF的重写机制

概念

随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制用来压缩文件的体积.AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件中

重写后的AOF文件体积为什么可以变小:

• 进程内已经超时的数据不再写入到文件中
• 旧的AOF中的无效命令,例如del,hdel,srem等重写后将会删除,只需要保留数据的最终版本
• 多条写操作合并为一条,例如:lpush list a,lpush list b,lpush list c可以合并为lpush list a b c.

较小的AOF文件一方面降低了硬盘空间的占用,一方面可以提升启动Redis时数据恢复的速度

触发重写机制

触发重写机制分为:手动触发和自动触发

• 手动触发:调用bgrewriteaof命令
• 自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发的时机(在配置文件中可自行配置)
  • auto-aof-rewrite-min-size:表示触发重写时AOF的最小文件大小,默认为64MB
  • auto-aof-rewrite-percentage:代表当前AOF占用大小相比较上次重写时增加的比例

AOF重写流程

• 执行AOF重写请求:如果当前进程正在执行AOF重写,请求不执行.如果当前进程正在执行bgsave操作,冲写命令延迟到bgsave执行结束之后再执行
• 父进程执行fork创建子进程
• 重写:不关心原来的AOF文件的状态,子进程只需要把内存中当前的数据获取出来,再以AOF的格式写入到一个新的AOF文件中
  • 主进程fork之后,继续响应其他命令.所有修改操作写入AOF缓冲区之后再根据appendfsync策略同步到硬盘中,保证旧AOF文件机制正确
  • 子进程只有fork之前的所有内存信息,父进程中需要将fork之后这段时间的修改操作写入到AOF重写缓冲区中
• 子进程根据内存快照,将命令合并到新的AOF文件中去
• 子进程完成重写
  • 新文件写入后,子进程发送信号给父进程
  • 父进程把AOF重写缓冲区内临时保存的命令追加到新的AOF文件中
  • 用新AOF文件替换老的AOF文件

启动时数据恢复

当Redis启动时,会根据RDB和AOF文件的内容,进行数据恢复
根据持久化文件进行数据恢复

混合持久化

混合持久化结合了RDB和AOF的特点,按照aof的方式,每一个请求/操作,都记录写入aof-use-rdb-preamble文件中,在触发aof重写之后,就会把当前的内存状态按照rdb的二进制格式写入到新的AOF文件中,后续在进行操作,仍然是按照aof的文本格式追加到文件后面

总结

• Redis提供了两种持久化的方案:RDB和AOF
• RDB视为内存快照,产生的内容更为紧凑,占用空间小,恢复速度更快.但是产生RDB的开销较大,不适合进行实时持久化,一般用于冷备和主从复制
• AOF视为对修改命令保存,在恢复时需要重放命令.并且有重写机制来定期压缩AOF文件
• RDB和AOF都是用fork来创建子进程,利用Linux子进程拥有父进程内存快照的特点来进行持久化,尽可能不影响主进程继续处理后续命令.