Redis持久化
* Redis主要是工作在内存中。
* 内存本身就不是一个持久化设备，断电后数据会清空。
* 所以Redis在工作过程中，如果发生了意外停电事故，如何尽可能减少数据丢失。
持久化方式
* RDB (Relational Database)
* AOF (Append Of File)
一. RDB
1. RDB简介
RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘，
也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。
2. 工作机制：
每隔一段时间，就把内存中的数据保存到硬盘上的指定文件中。
3. RDB 是默认开启的！
4. 操作过程
Redis 会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，
待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO 操作的，
这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。
5. RDB 的缺点是最后一次持久化后的数据可能丢失。
6. RDB 数据丢失的情况:
两次保存的时间间隔内，服务器宕机，或者发生断电问题。
二. AOF
1. AOF简介
AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，
都把新建、修改数据的命令保存到指定文件中。
Redis 重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
2. 默认不开启，需要手动开启
3. AOF文件的保存路径，同RDB的路径一致。
4. AOF在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！
5. 当RDB和AOF存的不一致的情况下，按照AOF来恢复。因为AOF是对RDB的补充。
备份周期更短，也就更可靠。
备份建议
1. 如何看待数据“绝对”安全
Redis 作为内存数据库从本质上来说，如果不想牺牲性能，就不可能做到数据的“绝对”安全。
RDB 和 AOF 都只是尽可能在兼顾性能的前提下降低数据丢失的风险，如果真的发生数据丢失问题，尽可能减少损失。
2. 在整个项目的架构体系中，Redis大部分情况是扮演“二级缓存”角色。
3. 二级缓存适合保存的数据:
经常要查询，很少被修改的数据。
不是非常重要，允许出现偶尔的并发问题。
不会被其他应用程序修改。
4. 如果 Redis 是作为缓存服务器，那么说明数据在 MySQL 这样的传统关系型数据库中是有正式版本的。数据最终以 MySQL 中的为准。
官方建议
官方推荐两个都用；
如果对数据不敏感，可以选单独用RDB；
不建议单独用AOF，因为可能出现Bug;
如果只是做纯内存缓存，可以都不用;