不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
（4）唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，做冷备不太合适。
你刚才提到冷备，那你具体说说为啥AOF不适合RDB适合？其实两个都可以做，只不过RDB更适合。
RDB可以做冷备，是因为它会生成多个文件，每个文件都代表了某一个时刻的完整的数据快照，我们可以将这种完整的数据文件发送到一些远程的安全存储上去，比如可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据。
AOF也可以做冷备，只不过它只有一个文件，但是我们可以去自己写程序，每隔一定时间，去copy一份这个文件出来。
RDB做冷备，优势在于由redis去控制固定时长生成快照文件的事情，比较方便，而 AOF，还需要我们自己写一些脚本去做这个事情，各种定时，比较麻烦。
RDB数据做冷备，在最坏的情况下，提供数据恢复的时候，速度比AOF快。
说了那么多AOF和RDB，那么生产系统对于这俩持久化机制到底该如何选择呢？至于，RDB和AOF到底该如何选择，我觉得两种都选择，
1）不要仅仅使用RDB，因为那样会导致你丢失很多数据。
2）也不要仅仅使用AOF，因为那样有两个问题，
第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快;
第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug。
3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复，作为数据恢复的最后一道防线。
好，今天就到这里，下次我们继续聊终于结束了。
其实如果你的简历上写了掌握Redis，那么如果面试官也比较精通Redis的话，他就会抓住你这一个Redis从浅入深的一直追着问，看看你到底对Redis了解多少，是不是平时自己真的积累过这些知识，是不是比别人要懂得多一点，经过一层一层的深挖，看看你能过几关。相对于其他竞争者可能几个回合就招架不住了，你要是能多战几个回合，面试官对你的印象也会越深，你的机会也就越大。
如果说就redis问你几个基础的问题，那面试官要么对redis了解不多，要么就看中了你简历中的其他亮点。
本系列文章在于面试突击，不是教程，要是细挖能讲好多，而面试你只需要把这个原理说出来就行了，如果边讲边画图那就更好了。
该系列文章在于快速突击，快速拾遗，温习。