这时候很可能，大量的请求过来，在缓存全部无法命中，这个时候就死定了，可能会导致缓存雪崩问题，所有的请求，没有在Redis命中，就会去数据库中去找，数据库一下子承接高并发，然后就挂了。数据库挂掉，你都没法去找数据恢复到redis里面去。
Redis持久化机制有哪些？Redis有两种持久化机制，AOF和RDB。
AOF，记录每次写请求的命令，以追加的方式在文件尾部追加，直接在尾部追加，效率比较高。
对于操作系统来说，不是每次写都直接写到磁盘，操作系统自己会有一层cache，redis写磁盘的数据会先缓存在os cache里，redis每隔1秒调用一次操作系统的fsync操作，强制将os cache中的数据刷入AOF文件中。
当redis重启的时候，就把AOF中记录的命令重新执行一遍就可以了，但是如果文件很大的话，执行会耗费较多的时间，对于数据恢复来说耗时会多一点。
RDB，是快照文件，每隔一定时间将redis内存中的数据生成一份完整的RDB快照文件，当redis重启的时候直接加载数据即可，同样的数据比AOF恢复的要快。
说说这两种持久化机制各自的特点、优缺点吧好的。
RDB的优点
第一点就是他会生成多个数据文件，每个数据文件都代表了某一时刻redis中的数据，非常适合做冷备。
第二点，RDB持久化机制对redis对外提供的读写服务影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
第三点，相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。
AOF，存放的指令日志，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据的。
RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可。
RBD的缺点
1）故障时可能数据丢失的比AOF要多。
一般来说，RDB数据快照文件，都是每隔5分钟或者更长时间生成一次，这个时候一旦redis进程宕机，那么会丢失最近5分钟的数据。
这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多
2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
所以一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的。
AOF的优点
1）AOF可以更好的保护数据不丢失
一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
每隔1秒，就执行一次fsync操作，保证os cache中的数据写入磁盘中。
redis进程挂了，最多丢掉1秒钟的数据.
2）AOF持久化性能高
AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
因为在rewrite log的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。
比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
AOF的缺点
（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成没写入一条数据，fsync一次，但是那样导致redis的QPS大幅度下降。
（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。
所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。