Redis 持久化之AOF持久化&混合持久化

上一篇提到了Redis的RDB持久化方式,同时也提到了一点关于AOF的内容。

RDB(snapshotting) 是一种内存快照的方式进行持久化,AOF(append-only-file)是通过追加写入命令的方式进行持久化,混合持久化是指RDB和AOF协同完成持久化工作来发挥各自有点的持久化方式。

AOF中的核心配置有这么三项:appendonly(是否打开AOF功能)、appendfilename(AOF文件的名称)、appendfsync(具体的同步的频率,always:每个Redis命令都要同步写入磁盘、everysec 每秒批量同步至磁盘、no:操作系统来决定什么时机落盘)

image.png

然后Redis 中是按照RESP协议格式来保存命令内容的,有兴趣可以看一下:

https://redis.io/topics/protocol

很显然,如果命令操作量非常大的时候,与RDB不同,AOF因为是追加命令,所以很大概率上AOF持久化文件会越来越大。这里AOF提供了一种优化策略策略。用户可以选择BGREWRITEAOF命令,来后台执行重写AOF文件命令,这个过程中会消除冗余的命令,来尽可能的减小AOF大小。(实际上还是会很大,效果其实一般啦,并且如果AOF文件已经非常大了,重写是一种比较影响Redis性能的使用方式,不推荐使用,具体场景具体分析吧)

和动态重写相关的配置有这么几项:auto-aof-rewrite-percentage用来指定AOF文件需要比旧AOF文件增大多少时才进行AOF重写。auto-aof-rewrite-min-size 用来指定AOF到达多大体积时才进行AOF重写,Redis 就是用这两个配置来控制AOF重写的(同时达到时才进行重写),整个重写的过程和BGSAVE比较相似,都是通过fork子进程来对AOF文件进行重写的。

image.png

从实现角度来看,AOF持久化大致分为命令追加、文件写入、文件同步三个步骤

当一条命令写入时,会以上面提到的协议格式话被执行的命令然后追加到服务器状态的aof_buf缓冲区的末尾,服务器执行完写命令之后,调用propagate进行命令追加。然后Redis的服务器进程实际上是一个事件循环,文件时间负责处理客户端的命令请求,时间时间负责执行一些定时执行的函数。在处理文件时间执行写命令,使命令被追加到aof_buf中,然后在处理时间时间执行的serverCron函数会调用flushAppendOnlyFile函数进行文件的写入、同步。

上面提到了在重写是通过fork子进程来执行的,这样主要是为了防止长时间阻塞主进程,在子进程重写的期间,主进程可以继续处理命令,不使用线程的原因是,开一个新的线程是无法携带主进程数据副本的,也就没办法避免与主进程竞争db->dict。至于主进程数据与子进程的数据副本不一致的问题而言,redis设置了AOF重写缓冲区,在子进程重写期间,主进程执行的每一个写命令都会写到重写缓冲区,然后子进程完成重写之后,再将重写缓冲区的数据写入到重写的AOF文件中,这样就能保证数据状态的一致性啦。

混合持久化:

混合持久化是Redis 4.X之后的一个新特性,说是新特性其实更像是一种RDB&AOF的结合,持久化文件变成了RDB + AOF,首先由RDB定期完成内存快照的备份,然后再由AOF完成两次RDB之间的数据备份。这样就充分了利用了RDB 加载快,备份文件小等特点,也利用了AOF能尽可能不丢数据这个特性(进一步保证了数据一致性),当然了基本上丢失了AOF的可读性。加载过程就是按部分进行加载的,先按照RDB进行加载,然后把AOF命令追加写入就好了。在大多数场景下RDB + AOF的混合持久化模式其实还是很合适的。

你可能感兴趣的:(Redis 持久化之AOF持久化&混合持久化)