RBD（Redis DateBase）
- 自动备份：在指定的时间间隔内把数据快照写进磁盘
- 手动备份：
save：阻塞其他所有的任务
bgsave：后台进行save - 手动停止RDB保存规则方法：redis-cli config set save ""
redis-check-dump --fix filename.rdb：修复rdb文件
备份策略：
在一定的时间间隔内，如果修改的记录数超过某个值，就进行备份。默认是900秒内修改一条，300秒内修改10条或者60秒内修改10000条
RBD其他自动触发机制
- 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点
- 执行shutdown命令时，自动执行rdb持久化
备份策略原理
Redis的save m n，是通过serverCron函数、dirty计数器、和lastsave时间戳来实现的。
serverCron是Redis服务器的周期性操作函数，默认每隔100ms执行一次；该函数对服务器的状态进行维护，其中一项工作就是检查 save m n 配置的条件是否满足，如果满足就执行bgsave。
dirty计数器是Redis服务器维持的一个状态，记录了上一次执行bgsave/save命令后，服务器状态进行了多少次修改(包括增删改)；而当save/bgsave执行完成后，会将dirty重新置为0。
例如，如果Redis执行了set mykey helloworld，则dirty值会+1；如果执行了sadd myset v1 v2 v3，则dirty值会+3；注意dirty记录的是服务器进行了多少次修改，而不是客户端执行了多少修改数据的命令。
lastsave时间戳也是Redis服务器维持的一个状态，记录的是上一次成功执行save/bgsave的时间。
save m n的原理如下：每隔100ms，执行serverCron函数；在serverCron函数中，遍历save m n配置的保存条件，只要有一个条件满足，就进行bgsave。对于每一个save m n条件，只有下面两条同时满足时才算满足：
- 当前时间-lastsave > m
- dirty >= n
压缩：LZF压缩，会损耗一定的CPU性能，默认开启，建议开启
校验：CRC64校验，会损耗一定的CPU性能，默认开启，建议开启。
执行flushall会删除掉所有的记录，该情况满足自动备份条件，会立刻进行备份，但是备份的rdb文件为空
RBD缺点：
- 每隔一定时间进行一次保存，如果redis意外宕机，则会丢失最后一次snapshot
- 备份时需要fork一份当前的数据，需要额外的空闲空间，还会导致在一些毫秒级不能相应客户端请求
RBD优点
- RDB是一个非常紧凑的文件
- 备份时，只需要主进程fork一个子进程，接下来的任务都由子进程完成，可以最大化redis性能
- 与AOF相比，恢复大数据集的时候会更快一些。
AOF（Append only File）
记录Redis执行过的所有写操作，redis启动的时候会把aof文件中的所有命令从前到后执行一次，只允许追加文件。默认不使用
redis-cli appendonly.aof：使用aof文件进行恢复
redis-check-aof --fix filename.aof：修复aof文件命令。删除filename.aof文件中所有不符合aof语法的句子
备份策略
实时（always）：保存每一条写命令，对性能要求高，不会有数据丢失。
每秒（everysec）：每秒保存一次写命令，如果redis服务器宕机，会有数据丢失。默认采取每秒（everysec）
不追加（no）：不保存写命令
重写
当AOF文件越来越大到一定阈值的时候，redis会采取重写策略，将内容压缩。
AOF rewrite操作就是“压缩”AOF文件的过程，当然redis并没有采用“基于原aof文件”来重写的方式，而是采取了类似snapshot的方式：基于copy-on-write，全量遍历内存中数据，然后逐个序列到aof文件中。因此AOF rewrite能够正确反应当前内存数据的状态，这正是我们所需要的；
rewrite过程中，新的变更操作将仍然被写入到原AOF文件中，同时这些新的变更操作也会被redis收集起来(buffer，copy-on-write方式下，最极端的可能是所有的key都在此期间被修改，将会耗费2倍内存)，当内存数据被全部写入到新的aof文件之后，原aof文件中收集的新的变更操作也将会一并追加到新的aof文件中，然后把新的aof文件重命名为appendonly.aof,此后所有的操作都将被写入新的aof文件。
如果在rewrite过程中出现故障，将不会影响原AOF文件的正常工作，只有当rewrite完成之后才会切换文件，因此rewrite过程是比较可靠的。
AOF缺点**
- 恢复相同大小的数据，AOF文件远大于RDB，运行效率也低于RBD
- aof文件rewrite操作，把数据压缩写到新的文件中的时候会导致几乎无法避免的阻塞。
AOF优点
- aof文件可读性好
- 数据完整新好，最坏只会丢失2s的数据
RBD和AOF
- redis启动的时候自动从rbd或aof文件中恢复数据。
- RBD和AOF两种恢复机制可以共存。两者共存时，redis启动时优先使用AOF恢复数据，如果AOF文件中出现错误，则无法启动redis
- RBD只作后备用途，建议在Slave上使用RDB策略，且只需要15分钟保存一次。
- 启用AOF，好处是最坏情况下也只损失2秒的数据。但是会带来新的问题
- aof文件rewrite操作，把数据压缩写入新的文件中的时候会导致几乎无法避免的阻塞。
- 导致持续的IO
- 如果不用AOF，只在主从模式下启用RBD，也可以实现高可用。只是当主从服务器同时挂掉的时候会损失15分钟的数据，而且恢复数据时需要比较主从服务器上的数据，选择其中较新的来恢复
