redis提供了rdb和aof两种持久化机制，

  • rdb默认开启，aof默认关闭。
    当两种持久化机制都开启时，redis重启恢复数据时加载aof持久化的 appendonly.aof``文件，而rdb持久化的** dump.rdb**文件不会被加载到内存中。

开启rdb，关闭aof

通过redis-cliSHUTDOWN这种方式停掉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节点数据清空。

原文链接：