Redis持久化
Redis 是内存型数据库，为了保证数据在断电后不会丢失，需要将内存中的数据持久化到硬盘上。
RDB 持久化（默认）
RDB: Redis DataBase
将某个时间点的所有数据都存放到硬盘上。
可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。
如果系统发生故障，将会丢失最后一次创建快照之后的数据。
如果数据量很大，保存快照的时间会很长。
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建 （ fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。
- 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
- RDB的缺点是最后一次持久化后的数据可能丢失。
- 我们默认的就是RDB，一般情况下不需要修改这个配置!
触发机制
1、save的规则满足的情况下，会自动触发rdb规则
2、执行flushall命令，也会触发我们的rdb规则!
3、退出redis，也会产生rdb文件!
备份就自动生成一个dump.rdb
恢复rdb文件？
只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据!
优点∶
- 适合大规模的数据恢复!
- 对数据的完整性要不高!
缺点∶
- 需要一定的时间间隔进程操作!如果redis意外宕机了，这个最后一次修改数据就没有了!
- fork进程的时候，会占用一定的内存空间!!
AOF 持久化
将写命令添加到 AOF 文件（Append Only File）的末尾。
使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。有以下同步选项：
- always 选项会严重减低服务器的性能；
- everysec 选项比较合适(默认方式)，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；
- no 选项并不能给服务器性能带来多大的提升，而且也会增加系统崩溃时数据丢失的数量。
随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF重写 的特性，能够去除 AOF 文件中的冗余写命令。
缺点︰
- 相对于数据文件来说，AOF 远远大于 RDB，修复的速度也比 RDB 慢!
- AOF运行效率也要比RDB 慢，所以我们redis默认的配置就是RDB持久化!
AOF 文件重写
和生成 RDB 文件时类似，在执行 AOF 重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的 AOF 文件中。
例如，如果数据库中包含三个键 k1、k2、k3，并且 k2 已经过期，那么在进行重写工作时，程序只会对 k1 和 k3 进行重写，而 k2 则会被忽略。因此，数据库中包含过期键不会对 AOF 重写造成影响。
