Redis的持久化-AOF
1.AOF
AOF(Append Only File)持久化:以独立日志的方式记录每次写命令,重启时在重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。理解掌握好AOF持久化机制对我们兼顾数据安全和性能非常有帮助。
有人就要问了:引入AOF之后,又要写内存,又要写硬盘,还能和之前一样快吗?
实际上影响是不大的,并没有影响到Redis处理请求的速度,原因在于: 1.AOF机制并非是直接让工作线程把数据写入硬盘,而是先写入一个内存缓冲区,积累一定数量的数据后,在统一写入硬盘(这样大大降低了些硬盘的次数)
2.硬盘上读写数据,顺序读写的速度是比较快的(当相比于写内存还是要慢很多),随机访问则是比较慢的。AOF每次把新的操作写入到原有文件的末尾,属于顺序读写
2.AOF的使用
2.1 使用AOF
开启AOF功能需要设置配置:appendonly yes,默认不开启。AOF文件名通过appendfilename配置(默认是appendonly.aof)设置。保存目录同RDB持久化方式一致,通过dir配置指定。AOF的工作流程操作:命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)
2.2 AOF工作流程
1.所有写入命令会追加到aof_buf(缓冲区)中
2.AOF缓冲区根据对应的策略向硬盘做同步操作
3.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的
4.当Redis服务器启动时,可以加载AOF文件数据恢复
2.3 命令写入
AOF命令写入的内容直接是文本协议格式,在AOF缓冲区会追加文本内容
Redis选择文本协议的可能原因:文本协议具有较好的兼容性,实现简单,具备可读性
AOF过程中为什么需要aof_buf这个缓冲区? Redis使用单线程响应命令,如果每次写AOF文件都直接同步硬盘,性能从内存的读写编程IO读写,必然会下降。先写入缓冲区可以有效减少IO次数,同时,Redis还可以提供多种缓冲区同步策略,让用户根据自己的需求做出合理的平衡
2.4 文件同步
Redis提供了多种AOF缓冲区同步策略,由参数appendfsync控制。
AOF缓冲区同步文件策略
可配置值 | 说明 |
always | 命令写入aof_buf后调用fsync同步,完成后返回 |
everysec(默认) | 命令写入aof_buf后只执行write操作,不进行fsync。每秒由同步线程进行fsync |
no | 命令写入aof_buf后只执行write操作,由OS控制fsync频率 |
系统调用write和fsync说明:
write操作会触发延迟写(delayed write)机制。Linux在内核提供页缓冲区用来提供硬盘IO性能。write操作在写入系统缓冲区立即返回。同步硬盘操作依赖于系统调度机制,例如:缓冲区页控件写满或达到特定时间周期。同步文件之前,如果此时系统故障宕机,缓冲区数据将丢失
fsync针对单个文件操作,做强制硬盘同步,fsync将阻塞直到数据写入到硬盘中
1.配置为always时,每次写入都要同步AOF文件,性能很差,在一般的SATA硬盘上,只能支持大约几百TPS写入。除非是非常重要的数据,否则不建议配置
2.配置为no时,由于操作系统不同策略不可控,性能虽然提高了,但是数据丢失风险大增,除非数据重要程度很低,一般不建议配置
3.配置为everysec(默认配置)时,兼顾了数据安全和性能。理论上最多丢失1秒的数据
2.5 重写机制
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件
重写后的AOF文件为什么会变小? 这是因为AOF文件中有一些内容是冗余的,Redis启动过程中读取AOF文件的内容,记录了中间的过程,实际上Redis在重新启动时只关注最终结果。
冗余的内容: 1.进程内已经超时的数据不再写入文件 2.旧的AOF中的无效命令,例如del,hdel,srem等重写后将会删除,只需要保留数据的最终版本 3.多条写操作合并为一条,例如lpush list a,lpush list b,lpush list c可以合并为lpush list a b c 较小的AOF文件一方面降低了硬盘空间占用,一方面可以提升启动Redis时数据恢复的速度
AOF重写过程可以手动触发也可以自动触发:
手动触发:调用bgrewriteaof命令
自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。 auto-aof-rewrite-min-size:表示触发重写时AOF的最小文件大小,默认为64MB auto-aof-rewrite-percentage:代表当前AOF占用大小相比较上次重写时增加的比例
AOF重写的流程
1.执行AOF重写请求(bgrewriteaof)。如果当前进程正在执行AOF重写,请求不执行,直接返回。如果当前进程正在执行bgsave操作(生成RDB快照),重写命令延迟到bgsave完成之后再执行
2.父进程执行fork创建子进程
3.重写 3.1)主进程fork之后,继续响应其他命令。所有修改操作写入AOF缓冲区并根据appendfsync策略同步到硬盘上,保证旧AOF文件机制正确 3.2)子进程只有fork之前的所有内存信息,父进程中需要将fork之后这段时间的修改操作写入AOF的重写缓冲区中
4.子进程根据内存快照,将命令合并到新的AOF文件中
5.子进程完成重写操作 5.1)新文件写入后,子进程发送信号通知父进程 5.2)父进程把AOF重写缓冲区临时保存的命令追加到新的AOF文件中 5.3)用新的AOF文件代替旧AOF文件
2.6 重启时数据恢复
当Redis启动时,会根据RDB和AOF文件的内容,进行数据恢复
Redis根据持久化文件进行数据恢复
当Redis同时存在AOF文件和RDB快照,此时以AOF为主,RDB直接被忽略(这是因为AOF中包含数据比RDB更全)
3.Redis持久化回顾
1.Redis提供了两种持久化方案:RDB和AOF
2.RDB视为内存的快照,产生的内容更为紧凑,占用空间较小,回复速度更快。但产生RDB的开销较大,不适合实时持久化,一般用于冷备和主从复制
3.AOF视为对修改命令的保存,在恢复时需要重放命令。并且有重写机制来定期压缩AOF文件
4.RDB和AOF都使用fork创建子进程,利用Linux子进程拥有父进程内存快照的特点进行持久化,尽可能不影响主进程继续处理后续命令