redis的持久化主要有两大机制，即AOF日志和RDB快照。

1、AOF日志是如何实现的？

与传统数据库写日志不一样，先执行命令，再写入日志。

比如：set testkey test value 这条命令的执行，AOF的日志内容是这样展示的

*3代表有当前命令有三个部分，3表示有三个字节，也就是set，3表示有三个字节，也就是set，3表示有三个字节，也就是set，7表示有7个字节,也就是testkey

为什么先执行和写日志呢，就是为了不出现语法错误导致恢复的时候出错，因为先写日志的话redis不会额外的检查语法的错误，这样错了的话导致后续恢复的时候出错。还有一个好处就是不会阻塞当前的写操作。

但是也有风险，Redis用作数据库的话，没来得及写日志就宕机了，这样无法恢复数据了。还有就是如果把日志文件写入磁盘阻塞，后续的操作也没法执行了。

2、三种写回策略

分别是同步写回Always，每秒写回Everysec，操作系统控制写回No。

高性能就选操作系统控制，高可用就选同步写回，这种就写每秒写回.

同样毕竟是文件系统，文件太大了怎么办？

3、日志文件太大了怎么办？

AOF重写机制为啥可以让文件变小呢？因为重写只会保持最新的记录，一个key对应的value是可能被多次修改的，那么在原本的日志文件就会存在多条记录。重写机制则只会存最新的记录。

4、AOF重写会阻塞吗？

重写是由后台线程bgrwriteaof来执行完成的，总结就是一个拷贝，两处日志。

一个拷贝就是主线程fork后台的bgrwriteaof子进程，fork会把主线程的内存拷贝一份给bgrwriteaof子进程，这里面就包含了数据库的最新数据，这个时候子进程就会把拷贝的数据写成操作，记入重写日志。

两处日志是，因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指正在使用的AOF日志，Redis会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个AOF日志的操作仍然是齐全的，可以用于恢复。

而第二处日志，就是指新的AOF重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的AOF文件，以保证数据库最新状态的记录。此时，我们就可以用新的AOF文件替代旧文件了。

总结来说，每次AOF重写时，Redis会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为Redis采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。

作者：狗日de阿良
链接：https://juejin.cn/post/6896072419543515143