（五）高并发redis学习笔记：RDB和AOF两种持久性机制的介绍以及优缺点对比

目录

1、RDB和AOF两种持久化机制的介绍
2、RDB持久化机制的优点
3、RDB持久化机制的缺点
4、AOF持久化机制的优点
5、AOF持久化机制的缺点
6、RDB和AOF到底该如何选择

我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的，持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去。比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用。
重启redis，尽快让它对外提供服务，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了。
很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会去mysql数据库这种数据源头中去找，一下子mysql承接高并发，然后就挂了。
mysql挂掉，你都没法去找数据恢复到redis里面去，redis的数据从哪儿来？大部分情况是从mysql来。
如果你把redis的持久化做好，备份和恢复方案做到企业级的程度，那么即使你的redis故障了，也可以通过备份数据，快速恢复，一旦恢复立即对外提供服务。

redis持久化：RDB，AOF

---

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

RDB持久化机制，是对redis中的数据执行周期性的持久化，也就是每隔几分钟或者几个小时（这个阈值是可以配置的），就会生成一份redis内存当前数据完整的快照。那么有一个疑问，一直生成，那文件不是会很多，占用空间么？实际上我们可以配置删掉之前的文件，只保留新鲜的快照即可。

AOF机制，把每一条命令数据写入到os的cache中，每隔一秒（很短间隔），就会调用操作系统的fsync操作将写入数据的命令刷到AOF