redis的持久化主要有两大机制,即AOF日志和RDB快照。
与传统数据库写日志不一样,先执行命令,再写入日志。
比如:set testkey test value 这条命令的执行,AOF的日志内容是这样展示的
*3代表有当前命令有三个部分,3表示有三个字节,也就是set,3表示有三个字节,也就是set,3表示有三个字节,也就是set,7表示有7个字节,也就是testkey
为什么先执行和写日志呢,就是为了不出现语法错误导致恢复的时候出错,因为先写日志的话redis不会额外的检查语法的错误,这样错了的话导致后续恢复的时候出错。还有一个好处就是不会阻塞当前的写操作。
但是也有风险,Redis用作数据库的话,没来得及写日志就宕机了,这样无法恢复数据了。还有就是如果把日志文件写入磁盘阻塞,后续的操作也没法执行了。
分别是同步写回Always,每秒写回Everysec,操作系统控制写回No。
高性能就选操作系统控制,高可用就选同步写回,这种就写每秒写回.
同样毕竟是文件系统,文件太大了怎么办?
AOF重写机制为啥可以让文件变小呢?因为重写只会保持最新的记录,一个key对应的value是可能被多次修改的,那么在原本的日志文件就会存在多条记录。重写机制则只会存最新的记录。
重写是由后台线程bgrwriteaof来执行完成的,总结就是一个拷贝,两处日志。
一个拷贝就是主线程fork后台的bgrwriteaof子进程,fork会把主线程的内存拷贝一份给bgrwriteaof子进程,这里面就包含了数据库的最新数据,这个时候子进程就会把拷贝的数据写成操作,记入重写日志。
两处日志是,因为主线程未阻塞,仍然可以处理新来的操作。此时,如果有写操作,第一处日志就是指正在使用的AOF日志,Redis会把这个操作写到它的缓冲区。这样一来,即使宕机了,这个AOF日志的操作仍然是齐全的,可以用于恢复。
而第二处日志,就是指新的AOF重写日志。这个操作也会被写到重写日志的缓冲区。这样,重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的AOF文件,以保证数据库最新状态的记录。此时,我们就可以用新的AOF文件替代旧文件了。
总结来说,每次AOF重写时,Redis会先执行一个内存拷贝,用于重写;然后,使用两个日志保证在重写过程中,新写入的数据不会丢失。而且,因为Redis采用额外的线程进行数据重写,所以,这个过程并不会阻塞主线程。
作者:狗日de阿良
链接:https://juejin.cn/post/6896072419543515143