redis的RDB和AOF持久性机制的优缺点

RDB持久化机制，对redis中的数据执行定期持久化。

AOF机制将每个写命令视为一个日志，并以仅附加模式写入日志文件。当redis重新开始比对时，可以通过回放AOF日志中写的指令来重建整个数据集。

如果同时使用AOF和RDB持久性机制，当redis重新启动时，将使用AOF来重建数据，因为AOF的数据更完整。

优势:

(1)RDB会生成多个数据文件，每个数据文件代表某一时刻redis的数据。这种多数据文件的方式非常适合冷备用。文件可以存储在云端、本地磁盘等。

(2)RDB机制对redis提供的外部读写服务影响很小，可以保持redis的高性能，因为redis的主进程只需要一个fork子进程，这样子进程就可以进行磁盘IO操作来持久化RDB。

(3)与AOF持久化机制相比，直接基于RDB数据文件重启和恢复redis进程更快。

缺点:

(1)如果你想让redis失败并且丢失尽可能少的数据，RDB不如AOF。因为一般情况下，RDB数据快照文件基本上每5分钟或更长时间生成一次。此时，如果出现停机，这段时间内的所有数据都会丢失。

(2)RDB每次在fork子进程中执行RDB快照数据文件的生成，如果数据文件特别大，可能会导致客户端提供的服务暂停几毫秒甚至几秒。

优势:

(1)AOF可以更好地保护数据不丢失。一般情况下，AOF每1秒就会通过一个后台线程执行一次fsync操作，最多1秒丢失数据。

(2)AOF日志文件是以只追加的方式写的，没有磁盘寻址的开销，写性能很高，文件不易损坏。即使文件尾部损坏，也可以轻松恢复。只需打开文件，删除背后损坏的数据。

(3)即使3)AOF日志文件过大，也会有后台重写操作，不会影响客户端的读写。因为当重写日志时，指令会被压缩，并且会创建一个最小日志。创建新的日志文件时，旧的日志文件仍将照常写入指令。当生成新的日志文件时，稍后在旧的日志文件中写入的指令将合并到新的日志文件中。新的合并日志文件将在准备就绪时与旧的日志文件进行交换。那么旧的日志文件将被删除。

(4)4)AOF文件存储已执行的指令，因此该功能非常适合灾难性误操作的紧急恢复。例如，有人不小心用flushall命令清空了所有数据。只要此时后台重写没有发生，就可以立即复制AOF文件，删除最后一个flushall命令，然后把AOF文件放回去，这样就可以通过恢复机制自动恢复所有数据。

缺点:

(1)对于相同的数据，AOF的日志文件通常比RDB的数据快照文件大。

(2)AOF开启后，Redis服务支持的写QPS会比RDB支持的低，因为AOF一般配置为fsync日志文件每秒一次，fsync每秒一次的性能还是很高的。

(3)以前AOF有一个bug，就是通过AOF记录的日志恢复数据时，同样的数据没有恢复。因此，像AOF这样基于命令日志/合并/回放的更复杂的方式比基于RDB的方式一次持久化一个完整的数据快照文件更脆弱，更容易出现bug。但为了避免重写过程带来的bug，AOF并不是每次都根据旧的指令日志合并指令，而是根据当时内存中的数据重构指令，鲁棒性更好。

将两者结合起来，AOF被用作第一选择，以确保尽可能少的数据丢失，而RDB用于在AOP丢失或损坏的情况下更快地恢复数据。