亿级流量（一）Redis的RDB和AOF两种持久化机制

• RDB持久化：每隔一段时间，将内存中的数据dump出来一份快照
• AOF持久化：对每条写入命令做日志，以append-only的模式写入一个日志文件中。在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。

如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来钩心构建数据，因为AOF中的数据更加完整。

RDB持久化机制的优点

1. RDB会生成多个数据文件，每个数据文件代表了某个时刻中redis的数据。这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去。
2. RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis朱进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
   
   RDB每次写都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中；AOF每次都是要写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销的，速度肯定比RDB略慢
3. 相对于AOF持久化，直接基于RDB数据文件来重启和恢复redis进程，更加快速

RDB持久化机制的缺点

1. RDB丢数据可能比AOF丢得多，一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次。
   
   这个问题也是RDB最大的缺点，就是不适合做第一优先的恢复方案
2. RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒

AOF持久化机制的优点

1. AOF可以更好地保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作将os cache中的数据写入磁盘中，最多丢失1秒钟的数据
2. AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为再rewrite log的时候，会对其进行压缩，创建出一份需要恢复数据的最小日志出来，再创建新日志文件的时候，老的日志文件还是照常写入，当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
4. AOF日志文件的命令是非常可读的。

AOF持久化机制的缺点

1. 对于同一份数据来说，AOF日志文件通常比RDB快照文件更大
2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当前，每秒一次fsync，性能也还是很高的。
   
   如果要保证一条数据都不丢，需要AOF的fsync设置成每写入一条数据，fsync一次，但是这时redis的QPS大降。
3. AOF以前发生过bug。
4. 做数据恢复的时候会比较慢，做冷备不太方便。

RDB和AOF到底该如何选择

1. 不要仅仅使用RDB，因为那样会导致丢失很多数据
2. 也不要仅仅使用AOF，因为那样有两个问题
   1. 通过AOF做冷备，没有RDB做冷备恢复速度块
   2. RDB更加健壮
3. 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来快速恢复数据