Redis的持久化：RDB（Redis DataBase）、AOF（Append Only File）
一、Redis持久化之RDB（Redis DataBase）
1、RDB是什么？
- 在指定的时间间隔内将内存的数据集快照写入磁盘，也就是通常讲的snapshot快照，它恢复时将快照文件直接读到内存中。
- Redis会单独创建（fork）一个子进程来进行持久化，会将数据写到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化的文件。在整过过程中，主进程不进行任何io操作的，这就确保了极高的性能。
- 如果需要进行大规模的数据恢复，并且对数据恢复的完整性不是非常的敏感，那RDB方式要比AOF方式更加高效，RDB的缺点是最后一次持久化后的数据可能丢失。
2、Fork
fork的作用是复制一个与当前进程一样的进程，该进程与主进程完全一致。但是该进程成是主进程的一个子进程。
3、RDB保存的是dump.rdb文件
redis数据保存到磁盘上，磁盘还是以一定的文件存在（以dump.rdb文件存在）
4、配置位置 【上述文档4-Redis解析配置文件redisconf.docx中的snapshotting快照】
（1）save 【save 秒钟 写操作次数】
- save 900 1 900秒（15分钟）key修改过1次。
- save 300 10 300秒（5分钟）key修改过10次。
- save 60 10000 60秒（1分钟）key修改过10000次。
- save “” 禁用
（2）stop-writes-on-bgsave-error 【字面翻译：若后台保存错误，前台就要停止写】
默认配置：stop-writes-on-basave-error yes
如果配置成no，表示不在乎数据不一致或者其他的手段和控制。
（3）rdbcompression 【字面意思：是否启动压缩】
默认配置：rdbcompress yes
对于存储到磁盘的快照，设置是否进行压缩存储。redis采用LZF算法进行压缩存储。
（4）rdbchecksum 【字面意思：压缩后进行校验】
默认配置：rdbchecksum yes
在存储快照后，使用redis中CRC64算法校验，校验大约增加10%的性能消耗。
（5）dbfilename 就是dump.rdb
（6）dir 目录，利用config get dir即可获得
5、如何触发RDB的snapshotting快照 【下面三种方法】
（1）配置文件中磨人的快照配置：冷拷贝后重新使用（可以cp dump.rdb dump_new.rdb）
（2）命名save或者bgsave
- save：save时只管保存，其它不管，全部阻塞。
- bgsave：redis会在后台异步进行快照操作，快照同时可以响应客户端请求。利用lastsave命名获取最后一次成功执行快照的时间。
（3）执行flushall命名，也会产生dump.rdb文件，但里面是空的，无意义。【无意义，不使用这个】
6、如何恢复
将备份文件dump.rdb移动到redis安装目录并启动服务即可。
7、优势和劣势
优势：（1）适合大数据的数据恢复；
（2）对数据的完整性和一直性不高。
劣势：（1）在一定时间做一次备份，如果在该时间内意外down，就会造成数据丢失；
（2）在fork时，将内存的数据会克隆一份，会造成大致2倍的膨胀性，此时性能需要考虑。
8、如何停止
动态所有停止RDB保存规则的方法：redis-cli config set save “”
9、小总结
【RDB最大的缺陷：会丢失最后备份的数据】
二、Redis持久化之AOF（Append Only File）
1、AOF是什么？
以日志的形式来记录每个写操作（增删改），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2、怎么配置
AOF保存的是appendonly.aof文件 【对应Redis解析配置文件redisconf.docx中的APPEND ONLY MODE】
aof默认是未开启的，在redis.conf文件的APPEND ONLY MODE模块下设置：
appendonly yes # 设置为yes开启
appendfilename "appendonly.aof" # 指定记录指令的文件名，默认即为appendonly.aof
【注1：rdb文件(dump.rdb)和aof文件(appendonly.aof)文件可以同时存在！若两者同时存在，默认使用aof文件！（先加载aof文件）】
【注2：appendonly.aof文件保存的位置在SNAPSHOTTING模块下dir配置项指定的位置，或在redis中输入 config get dir 命令也能获取其路径。】
APPEND ONLY MODE包含以下几个部分：
（1）appendonly 默认是appendonly no 默认就是no，yes就是打开aof持久化
（2）appendfilename 默认是appendfilename appendonly.aof
（3）appendfsync 默认是appendfsync everysec appendfsync有三个选项
- always 每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能
- everysec 每秒执行一次同步，显式地将多个写命令同步到硬盘
- no 让操作系统来决定应该何时进行同步
（4）no-apendfsync-on-rewrite 重写时是否可以运用appendfsync，用默认no即可，保证数据安全性
（5）auto-aof-rewrite-min-size 设置重写的基准值
（6）auto-aof-rewrite-percentage 设置重写的基准值
3、AOF启动/修复/恢复
（1）正常恢复：
启动：设置yes，修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录（config get dir）
恢复：重启redis然后重新加载
（2）异常恢复
启动：设置yes，修改默认的appendonly no，改为yes
备份被写坏的AOF文件
修复：redis-check-aof –fix 进行修复
恢复：重启redis然后重新加载
4、Rewrite
（1）Rewrite是什么？
AOF采用文件追加方式，文件越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
（2）重写原理： 【这点和快照有点类似】
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件
（3）触发机制：
redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
5、优势和劣势
优势：（1）每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性较好
（2）每修改同步：appendfsync everysec 异步操作，每秒记录，如果一秒宕机，有数据丢失
（3）不同步：appendfsync no 从不同步
劣势：（1）相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
（2）aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
6、小总结
三、Redis持久化RDB和AOF的实践使用
- 如果redis只做缓存服务器，那么可以不使用任何持久化方式。
- 同时开启两种持久化方式，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；RDB的数据不完整时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？ 作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
- 因为RDB文件只用作后备用途，建议只在slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
- 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
- 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。
