▌大纲

• RDB和AOF两种持久化机制的介绍
• RDB持久化机制的优点
• RDB持久化机制的缺点
• AOF持久化机制的优点
• AOF持久化机制的缺点
• RDB和AOF到底该如何选择

?

▌RDB和AOF两种持久化机制的介绍

1、redis默认情况下，每隔一秒，调用一次操作系统fsync函数，强制将os cache中的数据刷入到磁盘文件中。

2、redis中的内存大小是有一定限度的，当达到一定程度时将会用缓存淘汰算法，LRU，自动将一部分数据从内存中清除

3、当AOF文件大小达到一定程度时，将做rewrite操作，也就是基于当时redis内存中的数据，重新构建一个更新的AOF文件，删除旧的AOF文件

?

▌RDB持久化机制的优点

1、RDB会生成多个数据文件，每个数据文件都代表了某一时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备份，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据。
? ?RDB做冷备，优势在哪？由redis去控制固定时长生成快照文件的事情，比较方便；而AOF需要自己写一些脚本去做这个事情，各种定时

2、RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
? ?RDB，每次写，都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘
? ?AOF，每次都是要写文件，虽然可以快速写入os cache中，但是还是有一定的时间开销，速度肯定比RDB慢一些

3、相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
? ?AOF，存放的指令日志，做数据恢复时，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据
? ?RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可

?

▌RDB持久化机制的缺点

（1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候一旦redis进程宕机，那么丢失最近5分钟的数据
（2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者几秒。一般不要让RDB的间隔太长，否则每次生成的RDB文件太长了，对redis本身的性能不好
?

?

▌AOF持久化机制的优点

（1）AOF可以更好的保护数据不丢失，一般AOF会隔1秒，通过一个后台线程执行一次fsync操作，最多丢失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，性能也还是很高的。

（3）做数据恢复的时候，比较慢，并且做冷备份时不太方便，需要自己写复杂的脚本。

?

▌RDB和AOF如何选择

（1）不要仅仅使用RDB，因为那样会导致你丢失很多数据。

（2）不要仅仅使用AOF，因为那样有两个问题，一：AOF做冷备份慢 二：RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug。

（3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备份，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

?

?

?

?

?

cs