redis AOF持久化的配置和工作流程

事实上，redis中的数据是有限的。许多数据可能会自动过期，可能会被用户删除，也可能会被redis用缓存清除算法清除。Redis会不断地清除旧数据，只在内存中留下一些经常使用的数据。因此，一些已经被清除的数据执行命令仍然在AOF日志文件中，这将使AOF日志文件越来越大。因此，AOF每隔一段时间就会做一次重写操作。比如目前AOF存储的数据是100 w；此时10w的数据只存储在实际的redis中，所以此时会基于10w的数据建立一组最新的日志，并在a of中覆盖旧的a of文件，以保证AOF的日志文件不会太大，并与redis的内存保持一致。

重写策略配置

在redis2.4之前，你还需要手动开发一些脚本crontab，通过BGREWRITEAOF命令执行AOF重写，但是在2.4版本之后，你会自动重写，或者在redis.conf中配置它它的策略是:

以上策略配置的意思是:比如上次重写后，AOF文件是128M，然后在128M后继续写。如果发现增长比例超过了之前大小的100%，即256M，则会触发重写，但在触发之前，会将大小与min-size的64mb进行比较。如果

重写的工作流程

(1)redis fork的一个子过程。

(2)基于当前存储器中的数据，子进程建立日志，并开始将日志写入新的临时AOF文件。

(3)redis主进程收到客户端新的写操作指令后，将日志写入内存，新的日志指令也会写入旧的AOF日志文件中。

(4)子进程写完新的日志文件后，redis主进程将内存中新写的日志指令信息追加到这个新的AOF文件中。

(5)用新的AOF文件替换旧文件。

如果在redis向AOF文件追加数据时机器停机，可能会导致AOF文件损坏。重启redis之前，我们会找到AOF文件，用redis提供的工具修复它(执行以下命令修复AOF文件:)。

(1)如果RDB正在执行快照操作，redis不会执行重写；；如果redis执行AOF重写，那么redis不会执行RDB的快照。

(2)如果用户在redis执行快照时执行命令BGREWRITEAOF，redis将等到RDB快照生成后再执行重写。

(3)既有RDB的快照文件，也有AOF的日志文件。当redis重新启动时，将首先使用AOF日志文件，因为AOF文件中的数据更完整。