[大数据]Redis 的持久化机制和AOF文件重写原理，nginxlua开发实战pdf

二、AOF机制

AOF机制是将每一个写命令通过write函数保存到文件中，就好像日志记录一样，与RDB不同，AOF机制记录的不是内存中的数据，而是每一条命令。

这样随之而来一个问题：随着时间的推移，AOF文件体积会逐渐膨胀变得越来越大。为了解决这个问题，引入了“AOF文件重写机制”，该机制的原理将在后面谈到，重写之后的新AOF文件与旧文件相比，新旧两个文件所保存的数据库状态是相同的，但是新AOF文件不会包含浪费空间的冗余命令，因此文件重写机制能大大减小AOF文件的体积。

redis也提供了三种方式来触发AOF机制：always、everysec、no。

1. **always：**每次数据发生修改都会记录到磁盘，这种方式性能较差但数据完整性较好。

2. **everysec：**每秒记录一次数据，但如果一秒内发生了宕机，将会丢失这一秒钟内修改或新增过的数据。推荐使用这种方式。

3. **no：**从不同步数据。

三、RDB机制和AOF机制该如何选择？

正所谓小孩子才做选择，大人全都要。通常都是将两种机制结合使用比较好，当然如果场景特殊则参考下表自行定夺。

四、AOF文件重写原理

AOF重写并不需要对原来的AOF文件进行读取、写入和分析等操作，而是直接读取当前数据库状态来实现的。首先从数据库中读取键现在的值，然后用一条命令去记录键值对，用这一条命令代替之前记录该键值对的多个命令。

AOF文件重写涉及到两个重要的问题及解决办法如下。

1、aof_rewrite函数问题

AOF重写需要使用到aof_rewrite函数，这个函数会进行大量的写入操作，所以调用这个函数的线程将会发生长时间的阻塞，redis是使用单线程来处理命令的，如果直接使用aof_rewrite函数，那么redis将会在进行aof文件重写时无法处理客户端发送过来的命令请求。

解决这个问题的办法是将重写程序放入子进程中，子进程拥有主进程的数据副本，这样就能保证子进程在AOF文件重写期间，主进程依然能继续处理客户端的命令请求。

2、子进程进行文件重写存在的问题
看似完美，但使用子进程进行AOF文件重写时还会存在一个问题：子进程在进行文件重写期间，主进程依然能继续处理新的命令，如果新的命令使数据库数据发生了修改，那么当前数据库的数据和AOF重写之后的数据将会不一致。
为了解决这一问题，redis增加了一个AOF重写缓冲区，这个缓存在fork出子进程之后开始启用，Redis服务器主进程在执行完写命令之后，会同时将这个写命令追加到AOF缓冲区和AOF重写缓冲区，AOF缓冲区的内容会定期写入和同步到旧AOF文件中，这是为了保证旧AOF文件正常工作（因为此时新的AOF文件还没写完，所以旧的AOF文件需要正常工作），我

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

们重点关注AOF重写缓冲区，从创建子进程开始，主进程所处理的所有写操作都会被记录到AOF重写缓冲区，当子进程完成AOF文件重写（此时的AOF文件中的数据和当前数据库数据状态可能会不一致）之后会向主进程发送一个完成信号，主进程接收到这个信号后将会调用一个函数来完成以下操作：将AOF重写缓冲区中的内容全部写入新的AOF文件中，此时的AOF文件中的数据和当前数据库数据状态一致；对新的AOF文件进行改名覆盖原有的旧AOF文件，最终完成新旧AOF文件的替换。