转载至：https://www.cnblogs.com/wangfajun/p/5787077.html
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持久化配置
Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
AOF持久化配置
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
10.优化：
