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文件，载入较新 的那个。新浪微博就选用了这种架构