Redis之RDB与AOF

AOF定义:

以日志的形式记录每个操作,将Redis执行过的所有指令全部记录下来(读操作不记录),只许追加文件但不可以修改文件,Redis启动时会读取AOF配置文件重构数据
换句话说,就是Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。

Tip:

一.RDB与AOF同时开启  默认先加载AOF的配置文件
二.相同数据集,AOF文件要远大于RDB文件,恢复速度慢于RDB
三.AOF运行效率慢于RDB,但是同步策略效率好,不同步效率和RDB相同

1.RDB持久化(以快照的方式) 策略(默认):

save 900 1       (15分钟变更一次)
save 300 10     (5分钟变更10次)
save 60 10000  (1分钟变更1万次)

2.RDB默认配置文件名称:

dbfilename dump.rdb

3.表示是否开启AOF持久化:

appendonly yes(默认no,关闭) 

4.AOF持久化配置文件的名称:

appendfilename "appendonly.aof"

5.AOF持久化策略(默认每秒):

appendfsync always (同步持久化,每次发生数据变更会被立即记录到磁盘,性能差但数据完整性比较好)
appendfsync everysec (异步操作,每秒记录,如果一秒钟内宕机,有数据丢失)
appendfsync no  (将缓存回写的策略交给系统,linux 默认是30秒将缓冲区的数据回写硬盘的)

6.AOF配置文件损坏修复方法:

进入redis安装路径 执行 redis-check-aof --fix AOF配置文件名称

7.AOF的Rewrite(重写) :

定义:AOF采用文件追加的方式持久化数据,所以文件会越来越大,为了避免这种情况发生,增加了重写机制
当AOF文件的大小超过了配置所设置的阙值时,Redis就会启动AOF文件压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof
原理:当AOF增长过大时,会fork出一条新的进程将文件重写(也是先写临时文件最后rename),遍历新进程的内存数据,每条记录有一条set语句。
重写AOF文件并没有操作旧的AOF文件,而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件(有点类似快照)
触发机制:Redis会记录上次重写时的AOF文件大小,默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
auto-aof-rewrite-percentage 100  (一倍)
auto-aof-rewrite-min-size 64mb

8.RDB与AOF的选择:

做备份:当数据量大,且对恢复速度有要求,并且数据的一致性要求不高的话,可以只使用RDB

只做缓存:不用开启任何的持久化方式

两者都开启的建议:RDB数据不实时,同时使用两者时服务器只会找AOF文件,可不可以只使用AOF?建议不要,因为RDB更适合备份数据库(AOF在不断变化,不好备份),快速重启,而且不会又AOF可能潜在的BUG,留作万一的手段。

9.优化:

因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就眵了,只保留save 900 1这条规则

如果EnalbeAOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一 是带来了持续的10,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要哽盘 许可,应该尽量减少AOF rewrite的频率,A0F重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小 时重写可以改到适当的数值。

如果不Enable AOF,仅靠Master-Slave Replication实现髙可用性也可以。能省掉一大笔10也减少了rewrite时带来的系统波 动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新 的那个。新浪微博就选用了这种架构