AOF持久化的配置
还是在redis.conf中找属性appendonly 该属性
appendonly yes
image.png
如上图所示，这样就开启AOF机制的持久化了，AOF持久化默认是关闭的，redis默认是开启RDB持久化的。生产环境中一般AOF还是要开启的，除非可以容忍出现故障，可以丢失几分钟的数据。
打开AOF之后，redis每次接收到一个命令之后，就会写入日志文件中，当然先是写入os cache中，然后每隔一定时间再fsync一下。而且即使AOF和RDB都开启，在redis重启之后，也是会优先通过AOF进行数据恢复，因为AOF日志文件中的数据比较完整。
AOF的fsync的策略配置：
always：每次写入一条数据，就立即将这个数据对应的写日志fsync到磁盘上去，性能非常的差，吞吐量非常低，如果非要保证redis不能丢失数据，那就只能这样子了。
everysec：每秒将os cache中的数据fsync到磁盘，这个最常用，并且redis默认也是这个策略，生产环境一般也是这么配置，性能也很高，QPS可达到上万。
no：仅仅将数据刷入到os cache中就不管了，然后就只能靠os cache自己的刷盘策略，时不时的将os cache中的数据刷入磁盘。
image.png
AOF rewrite的工作流程分析
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中配置，它的策略：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
上面策略配置的意思是：比如上一次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文件替换旧的文件。
AOF破损文件的修复
如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件的破损，我们在重启redis之前，找到AOF文件，用redis自带的工具来修复它（执行下面的命令来修复AOF文件：）
redis-check-aof --fix aof文件
image.png
RDB和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文件中的数据更加完整。
网友评论