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

还是在redis.conf中找属性appendonly 该属性

redis中的数据其实是有限的，很多数据可能会自动过期，也有可能会被用户删除，还有可能会被redis用缓存清除的清除算法清除掉。redis会不断的淘汰旧的数据，只会留下一些常被使用的数据在内存中。所以，就会有一些已经被清除掉的数据执行命令还在AOF日志文件中，这样就会是AOF的日志文件越来越大，所以，AOF会自己每隔一段时间就做一次rewrite操作，比如目前AOF中存放的是100w的数据的写日志；而此时实际redis中才存放的10w的数据，那么此时就会基于这10w的数据构建一套最新的日志，到AOF中，覆盖之前的旧的AOF文件，确保AOF的日志文件不会太大，保持和redis内存数量一致。
rewrite 的策略配置
在redis2.4之前，还需要手动开发一些脚本，crontab，通过BGREWRITEAOF命令去执行AOF rewrite，但是在2.4版本之后，就会自动的进行rewrite，还是在redis.conf中配置，它的策略：

上面策略配置的意思是：比如上一次rewrite之后AOF文件是128M，然后就会接着128M继续写，如果发现增长的比例，超过之前大小的100%，也就是256M，那么就会触发一次rewrite，但是在触发之前还有和min-size的64mb比较一下大小，如果大于这个最小值，才触发。
rewrite的工作流程
（1）redis fork一个子进程。
（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志。
（3）redis主进程，接收到client新的写操作指令后，在内存中写入日志，同时新的日志指令也会在旧的AOF日志文件中写入。
（4）子进程写完新的日志文件之后，redis主进程将内存中新写入的日志指令信息追加到这个新的AOF文件中。
（5）用新的AOF文件替换旧的文件。

如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件的破损，我们在重启redis之前，找到AOF文件，用redis自带的工具来修复它（执行下面的命令来修复AOF文件：）

（1）如果RDB在执行snapshotting操作，那么redis不会执行rewrite；如果redis执行AOF rewrite，那么redis不会执行RDB的snapshotting。
（2）如果redis在执行snapshotting时，此时用户执行命令：BGREWRITEAOF，redis将等RDB快照生成之后，才会去执行rewrite。
（3）同时有RDB的快照文件和AOF的日志文件，在redis重启的时候，会优先使用AOF日志文件，因为AOF文件中的数据更加完整。