Redis持久化-AOF

AOF(Append only file)默认就是文件的无限追加

将我们的所有命令都记录下来,好比一个history文件,恢复的时候就把这个文件全部再执行一遍

以日志的形式来记录每一个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但是不可以改写(修改文件),Redis启动的时候的时候会读取该文件重新构建数据,换一句话来说,redis重启的话就根据日志文件的内容将写的指令从前到后执行一次以完成数据的恢复,如果是大数据情况下,效率会比较低,因为大量读写操作需要进行很久

AOF保存的数appendonly.aof文件,以下截图来自conf配置文件中APPEND ONLY MODE位置

AOF在conf中的相关配置

appendonly no #默认是不开启的,Redis默认开启的事RDB持久化方式,我们需要手动更换成yes表示开启AOF持久化方式
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof" #默认的保存文件名叫appendonly.aof,一般情况下不要改
#redis中AOF的默认策略
# appendfsync always  #每一次都去修改
appendfsync everysec #每一秒写一次 默认这个即可
# appendfsync no #不修改
no-appendfsync-on-rewrite no #重写的规则  是否进行一些重写 重写的时候是否用append重写,默认no 不使用 可以保证我们的数据安全性
#AOF重写的规则 保持默认即可
auto-aof-rewrite-percentage #重写的进度条是100
auto-aof-rewrite-min-size 64mb #重写的最大值是64兆B 超过这个会重写一些其他文件

例子:自定义测试AOF持久化

首先把conf文件中的appendonly 从no改为yes,默认是no不开启,有的版本或者操作系统在配置文件把appendonly no改为appendonly yes,但是不生效(我现在用的是windows),不会产生appendonly.aof文件,需要在cli客户端输入命令（注：想要生成appendonly.aof文件，必须要执行redis命令才会生成对应的命令记录，aof文件其实就是记录你执行过的redis命令）

redis-cli config set appendonly yes #把aof持久化开启 默认关闭的 这样就同时支持我们的rdb和aof两种,一般这个命令我们用的比较多
redis-cli config set save "" #关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能,执行了之后，服务器上面就生成了对应的appendonly.aof，一般这个文件主要是用来恢复redis数据库的

配置完成之后,重启我们的redis(shutdown)即可生效,(因为redis每秒都在进行生成),生成我们的appendonly.aof文件, 一般我们的aof和rdb都会进行生成

appendonly.aof其实就是个文件,以日志的形式记录我们的所有写操作,每秒都会记录我们的写操作,启动的时候去调用这个文件恢复数据,一般这个文件主要是用来恢复redis数据库的

如如对我们的aof文件有误或者被进行篡改,我们的redis是启动不起来的,我们需要修复这个配置文件,redis给我们提供了一个工具:redis-check-aof

1 故意篡改文件

2 使用redis-check-aof命令进行修复

redis-check-aof --fix appendonly.aof

3 这样就是成功修复了

4 修复成功后,再次查看我们的aof文件,发现已经被修复这时候再重启redis会正常启动

AOF默认就是文件的无限追加.如果文件过于大,就会触发我们的重写策略

AOF重写的参数是rewirte,默认不打开(no),rewirte重写的配置,重写规则说明如果AOF文件大于64m.就会fork一个新的进程来将我们的文件进行重写

#redis中AOF的默认策略
# appendfsync always  #每一次都去修改
appendfsync everysec #每一秒写一次 默认这个即可
# appendfsync no #不修改

AOF的优点

 1 每一次修改都同步,文件和数据的管理会更加安全

 2 根据redis的配置,因为redis是默认开启每秒同步一次,这样的话可能会丢失最后一秒的数据,如果一直同步会非常消耗性能,从不同步,效率是最高的

AOF的缺点

1 相对于数据文件来说,AOF远远大于RDB,修复的数据也比RDB慢

2 AOF是一个读写的IO操作.运行效率也要比RDB慢,所以我们Redis默认的配置就是RDB持久化

扩展:

1 如果只做缓存,希望数据在服务器运行的时候存在,不需要做任何持久化操作

2 如果同时开启两种持久化方式,首先启动redis的话会优先载入AOF文件来恢复原始的数据,因为通常情况下AOF文件保存的数据集要比RDB完整,两者同时开启消耗的性能也会很大

3 RDB的数据不实时.同时使用两者服务器也只会找AOF文件,那要不要只使用AOF呢,还是建议不要,因为RDB更适合用于备份数据库(AOF不断变化不好备份),而且AOF有潜在的BUG

4 性能建议:RDB文件一般只用作于备份数据,建议只在slave(从机)上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这一条规则

5 如果开启AOF持久化方式,最差的情况也只是丢失不超过两秒的数据,如果把AOF关掉的话,仅靠Mater-Slave Repllcation(主从复制)实现高可用也可以,key剩下一大笔IO消耗,也减少了rewrite(重写)时带来的系统波动,代价是Master/Slave同时宕机(最暴力的方式就是断电),会丢失十几分钟的数据,启动脚本的时候会比较Master/Slave(主机从机)中的RDB文件,哪个更新,哪个文件更大,就是我们最新的文件(数据),微博就是采用这种架构