一、RDB持久化
RDB（Redis DataBase）：
配置文件中对其的相关配置：
触发机制：
恢复rdb文件：
优点：
缺点：
二、AOF持久化
AOF（Append Only File）：
配置文件中对其的相关配置：
恢复aof文件：
优点：
缺点：
Redis中的数据存在内存中肯定是不安全的，所以需要将数据进行持久化操作，防止数据丢失造成的危害。
一、RDB持久化
RDB（Redis DataBase）：
在指定时间间隔内将内存中的数据快照集体写入磁盘，也就是Snapshot快照，恢复时将快照文件直接读到内存中。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中，待持久化过程都结束，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。
默认情况下是 RDB，一般不需要修改这个配置！
在主从复制中，rdb就是备用，从机上！
配置文件中对其的相关配置：
1、RDB保存的文件 dump.rdb （在生成环境中经常将rdb文件备份）
2、RDB默认的保存规则：900s中发生一次修改就进行保存
触发机制：
-
save的规则满足情况下，自动触发rdb规则
-
执行flushall命令，也会触发rdb规则
-
退出redis（shut down 合理退出命令），也会产生rdb文件
备份就自动生成一个 dump.rdb 文件
恢复rdb文件：
-
只需将rdb文件放在redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！
-
查看需要存放的位置：config get dir
优点：
-
适合大规模的数据恢复！（父进程不参与数据的保存恢复，而是fork子进程管理，效率高）
-
对数据完整性要求不高！（比如300s内更新了9次突然宕机了，那最后的数据没来得及保存就丢失了）
缺点：
-
需要一定的时间间隔进行操作！如果redis意外当即，最后一次修改数据就没
-
fork进程的时候，会占用一定的资源！
二、AOF持久化
AOF（Append Only File）：
以日志的形式将我们的所有命令都记录下来（写记录读不记录），秩序罪加文件不可更改文件，redis重启会去读该文件重新构建数据，换言之，把这个文件中指令全部再执行一遍。
配置文件中对其的相关配置：
1、保存在 appendonly.aof（默认不开启，开启需要手动配置）
2、持久化策略（默认每秒写一次）
3、重写规则
默认是文件的无限追加，文件会越来越大！
当文件大小超过64m，fork一个新的进程来讲我们的文件进行重写
恢复aof文件：
破坏/损坏 aof 文件后，无法启动redis（如果默认时aof模式下）
此时，可以用 redis-check-aof 来修复
优点：
-
每次修改都同步，文件的完整性会更好！
-
没秒同步一次，可能会丢失一秒的数据！
-
从不同步，效率最高的！
缺点：
-
相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢！
-
aof运行效率也要比rdb慢，所以redis默认配置是rdb！
性能建议：
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够 了。
如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的 AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后 将 rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，,默认超过原大小100%大小重写可以改到适当的数值。
如果不Enable AOF，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也 减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时挂了，会丢失十几分钟的数据， 启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。
