缓存雪崩

缓存同一时间大面积失效，后面的请求都会落到数据库上，造成数据库短时间内无法承受大量请求而崩溃

例如在电商首页，所有首页的key失效时间都是12小时，中午12点刷新，如果零点有个秒杀活动大量用户涌入，但是缓存当时所有key都失效，此时所有的请求会落到数据库，数据库扛不住，就直接就gg了，又或者redis宕机，也会让大量请求落到mysql，造成挂机。

解决方案

• 所以像这种情况就应该把每个key的失效时间加个随机值，避免同一时间大量的key失效，如果是redis集群部署，可以将热点数据分布到各个不同的库。

• 事前：尽量保证redis集群的高可用性，发现机器宕机尽快补上，选择合适的内存淘汰策略

• 事中：本地ehcache缓存+hystrix限流加降级，避免mysql崩掉

• 事后：里有redis持久化机制保存的数据尽快恢复缓存。

缓存穿透

大量请求的key不存在于缓存中，例如某个黑客制造缓存中不存在的key发起大量请求，导致大量请求落到数据库。

解决办法

• 首先应该要做基本的入参校验，将不合法的参数直接拦截，例如查询数据库id不能小于0，校验邮箱格式等等

• 如果缓存和数据库都查不到某个key的数据，就将key写入到redis，value为null，并设置过期时间，避免下次请求落到数据库上。

• 通过布隆过滤器，布隆过滤器可以非常方便的判定一个给定的数据是否存在与海量数据中.可以将所有可能存在的请求的值存到布隆过滤器，当请求过来先判断用户发来的请求是否存在于布隆过滤器，不存在就直接拦截。

缓存击穿

缓存击穿指的是一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key失效瞬间，持续的大并发就穿破缓存，直接请求到数据库

缓存一致性

如果是要求强一致性，那就不能使用缓存，因为保证不了强一致性，只能保证最终一致性。

• 先删除缓存，再更新数据库

如果数据库更新失败，那么数据库的还是旧数据，redis是空，数据不会不一致，读到空会去数据库进行查询，然后更新到缓存。

• 加入队列，进行串行化操作

先删除缓存，再更新数据库，在高并发场景下也会出现问题，例如删除了缓存，这时还没更新数据库，另一个线程进来，发现redis是空，会去读数据库，然后更新到redis,而此时删除了缓存的线程接着更新数据库，就会造成数据库和redis数据不一致，这时候可以将更新数据的操作放到队列当中，串行化操作，不会出现，但一般不建议这样做，因为会降低效率。