1.Redis持久化RDB有两种方式：RDB持久化机制实现对redis中数据的周期性持久化。AOF：AOF机制将每条写命令都视为一条日志，以append-only的方式写入到一个日志文件中。当redis重启时，可以通过回放AOF日志中的写命令来重构整个数据集。通过RDB或者AOF，可以将redis内存中的数据持久化到磁盘，然后可以将这些数据备份到其他地方，比如阿里云等云服务。如果redis挂了，服务器上的内存和磁盘上的数据都丢失了，可以从云服务中复制之前的数据，放到指定的目录下，然后重启redis，redis会根据数据自动存储到持久化数据文件中恢复内存中的数据，并继续对外提供服务。如果同时使用RDB和AOF两种持久化机制，当redis重启时，会使用AOF重建数据，因为AOF中的数据更完整。2、RDB的优缺点RDB会生成多个数据文件，每个数据文件代表redis在某个时刻的数据。这种多数据文件的方式很适合做冷备份，可以将这个完整的数据文件发送到一些远程安全存储，比如亚马逊的S3云服务，或者阿里云在国内的ODPS分布式存储，redis中的数据使用预定的备份策略定期备份。RDB对redis提供的读写服务影响很小，可以保持redis的高性能，因为redis主进程只需要fork一个子进程，让子进程进行磁盘IO操作，实现RDB持久化。相比AOF持久化机制，直接根据RDB数据文件重启恢复redis进程更快。如果想在redis失效的时候尽可能少的丢失数据，那么RDB不如AOF。一般来说，RDB数据快照文件每5分钟或更长时间生成一次。这时候你就不得不接受，一旦redis进程宕机，最后5分钟的数据就会丢失。RDB每次fork子进程执行RDB快照数据文件生成，如果数据文件特别大，可能会导致客户端提供的服务暂停几毫秒，甚至几秒。三、AOF的优缺点AOF可以更好的保护数据不丢失。一般AOF会每隔1秒通过后台线程进行一次fsync操作，最多丢失1秒的数据。AOF日志文件采用append-only方式写入，因此没有磁盘寻址开销，写入性能非常高，而且文件不易损坏，即使文件尾部损坏也很容易维修。即使AOF日志文件过大，后台rewrite操作也不会影响客户端的读写。因为在重写日志的时候，里面的指令会被压缩，创建一个需要恢复数据的最小日志。创建新日志文件时，旧日志文件仍照常写入。当新的合并日志文件准备就绪时，只需交换旧日志文件和新日志文件即可。AOF日志文件的命令以非常易读的方式记录，非常适合灾难性误删的应急恢复。例如，有人不小心用flushall命令清除了所有数据。只要这时候后台rewrite还没有发生，就可以马上复制AOF文件，删除最后的flushall命令，再把AOF文件放回去。通过恢复机制，自动恢复所有数据。同一条数据，AOF日志文件通常比RDB数据快照文件大。开启AOF后，支持的写QPS会低于RDB支持的，因为AOF一般配置为每秒fsync日志文件一次。当然每秒fsync一次，性能还是很高的。（如果是实时写入，那么QPS会大大降低，redis的性能也会大大降低。）之前AOF有过bug，就是AOF记录的日志用于数据恢复的时候，没有恢复完全相同的数据。因此，像AOF这种基于命令log/merge/playback的更复杂的方式，比基于RDB每次持久化一个完整的数据快照文件的方式更脆弱，更容易出现bug。但是AOF是为了避免rewrite过程带来的bug，所以每次rewrite都不会根据旧的指令log进行合并，而是根据当时内存中的数据重建指令，所以健壮性会好很多。4.RDB和AOF如何选择不要只用RDB，因为那样会丢失很多数据；不要只用AOF，因为有两个问题：第一，你用AOF做冷备份，不用RDB做冷备份，备份恢复速度更快；第二，RDB每次简单粗略的生成数据快照，更加健壮，可以避免AOF等复杂备份恢复机制的bug；redis支持同时启用两种持久化方式，我们可以综合使用AOF和RDB两种持久化机制，使用AOF保证数据不丢失，作为数据恢复的首选；使用RDB做不同程度的冷备份，当AOF文件丢失或损坏不可用时，仍然可以使用RDB进行数据的快速恢复。
