Redis 持久化
1、持久化的方式
Redis 提供了两种持久化方式，RDB 和 AOF
2、RDB（Redis DataBase）
简述：RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。
备份过程（默认）：
触发方式：
1）自动触发
在 redis.conf 文件中的 SNAPSHOTTING 描述中就提及了触发条件
大概意思就是说 save A B => 在 A 秒内若产生了 B 次对键的变化则进行一次持久化
三个 save 中满足其中某一个条件则将会进行持久化操作
2）手动触发（save命令、bgsave命令）
save：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。
bgsave：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
ps：执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的。
顺带一提，在 Redis 异常退出的时候，可能会丢失最后一次更新的结果，但是如果是通过shutdown退出，则会进行一次持久化操作
BTW：Redis 的配置文件对持久化还有其他可设置的选项如下
stop-writes-on-bgsave-error：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了
rdbcompression：默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
rdbchecksum：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
dbfilename：设置快照的文件名，默认是 dump.rdb
dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。默认的 ./ 是你在哪开启的 redis 它就在哪放置。
也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定。
恢复数据：
数据恢复 redis 会从配置文件的 dir 中获取 rdb 文件来进行恢复，你也可以在客户端采用命令 CONFIG GET dir 来查看备份目录，当然默认配置文件设置的就是 ./ 即你在哪个目录开启的 redis-server 则就是在哪个文件夹进行查找恢复，可以自己实验一下。
3、AOF（Append Only File)
简述：以日志形式来记录每个写操作，将 Redis 执行过的所有写指令记录下来，只允许追加文件但不可以改写文件，Redis 启动之初会读取该文件重新构建数据，即Redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
开启方式：
AOF 默认不开启，需要在配置文件中配置（配置文件中的 APPEND ONLY MODE）
将配置文件的 appendonly no 改为 yes 即可开启，在服务启动时则会加载备份，若此时 RDB 也开启，那么只恢复 AOF
备份文件的文件名如上所示，默认为 appendonly.aof，存储路径同 RDB 一致
触发条件：
always：始终同步，每条写记录都会被记入日志
everysec：每秒记录一次，丢失的话只会丢失秒的数据
no：把同步时机交给操作系统
Rewrite 机制：
1）bgrewriteaof 命令
即比如你执行了
set a 1
set a 2
set a 3
则重新之后，备份文件之后记录最后一次修改即 set a 3
2）重写的实现：
3）重写时机
4、Redis 4.0 混合持久化
