缓存雪崩

缓存雪崩

就是缓存宕机了，本来缓存中缓存的数据是可以满足正常的查询操作的，比如有5000个请求过来，其中4000个在正常情况下是可以走缓存的，但是现在缓存宕机了，就走不了了，所有的请求就都走数据库了，这时的数据库压力就非常大了，那数据库扛不住每秒5000个请求（假如数据库每秒只能扛2000个请求），这个时候数据库就会直接崩溃。

如果这个时候不做任何处理，只是重启数据库的话，重启后立马又会挂掉，因为没有缓存，系统就扛不住高并发。

如何解决缓存雪崩

实际上缓存雪崩是解决不了的，只能说是缓解。
分为事前、事中、事后这三个一体的方案

事前：保证redis集群的高可用性，缓存必须是高可用的（主从+哨兵，或者是redis cluster,至少保证一个高可用的架构），即使如此，redis集群也可能全盘崩溃

解决办法：不要将缓存放到redis这一级，在系统的内部再做一个小缓存，用ehcache来做，在系统内部用ehcache再维护一份缓存

过程如下：

1. 系统收到一个请求
2. 先去ehcache中去查看
3. 如果没有再去redis中找
4. 还没有再去和数据库进行交互
5. 查到之后再将结果放到ehcache和redis中

redis是放在系统外部做缓存的，ehcache是放在系统内部的

事中：
本地ehcache缓存+hystrix限流&降级,避免mysql被打死

使用限流的好处：

1. 首先你的数据库不会死，限流组件就限制了每秒就过去2000个请求
2. 只要数据库不死，对用户来说，2/5的请求是可以被处理的
3. 只要2/5的请求可以被处理，就意味着你的系统没死，对用户来说，就是可能点击几次刷不出来，多点几次就刷出来了

虽然这样做可能效率下来了，但是比缓存雪崩什么都做不了要好的多
内部缓存+限流组件来应对外面的缓存集群挂掉了的情况
事中最大的一个问题是，你要确保这个库不能死

事后：
reidis持久化机制，尽快恢复缓存集群，一旦重启，自动从磁盘上加载数据，恢复内存中的数据
只要挂掉的集群正常恢复，就又可以有4000个请求走缓存集群