redis AOF 和RDB

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 （不同步）

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.优化：

巴特西