redis提供了rdb和aof两种持久化机制，rdb默认开启，aof默认关闭。
当两种持久化机制都开启时，redis重启恢复数据时加载aof持久化的appendonly.aof文件，而rdb持久化的dump.rdb文件不会被加载到内存中。
情景：开启
rdb，关闭aof
通过redis-cli SHUTDOWN这种方式停掉redis，这是一种安全的退出方式，redis会在退出的时候将内存中的数据立即生成一份完整的rdb快照。
通过kill -9杀死redis进程，这种方式会导致redis异常退出，从而导致内存中的数据没有到达save指定的检查点，进而丢失内存中的数据。情景：开启
rdb，关闭aof，待dump.rdb有数据后，再开启aof
redis持久化dump.rdb后，启用aof持久化，再重启redis，redis只会加载aof持久化的appendonly.aof文件，如果它不存在，那会创建一个新的空的文件，从而导致内存中丢失dump.rdb的数据。解决方式：停止
redis，关闭aof，重启redis，确保dump.rdb数据恢复在内存中，使用命令行热修改redis配置的方式打开aof，此时redis就会以aof持久化的形式将内存中的数据写入appendonly.aof文件，然后停止redis，修改配置文件将aof手动打开。
情景：主从架构的
master关闭rdb和aof持久化，slave作为master的数据热备
在采用master-slave的水平扩展架构的时候，格外的需要注意：master必须要开启持久化，不建议用slave节点作为master节点的数据热备。
我们知道主从复制的架构中，所有的写操作交由master负责，slave分担读的操作，slave中的数据是从master同步过来的。假如master的rdb和aof都关闭了，数据全部在内存中，那么master宕机重启时，发现本地没有可以恢复的数据，导致master内存数据为空，然后master将空的数据集同步到slave节点，导致slave的数据全部清空。因此master必须要开启持久化！
即使我们采用高可用机制的哨兵模式，即master宕机时，slave节点通过选举转变为master节点，在这种情况下，可能哨兵模式还没检测到master节点宕机，master节点就自动重启了，因此还是可能导致所有slave节点数据清空。
