一、缓存雪崩
缓存雪崩：缓存雪崩是当缓存服务器重启或大量的缓存key在同一时间全部失效，导致大量请求打到数据库上，数据库承受不住压力，数据库挂掉。常见案例：
双十一期间，所有用户打开到淘宝首页都是进入到首页，首页的压力非常大，为了提高并发性，将网站首页的数据都从数据库缓存到redis中，所有的redis key的失效时间都设置为3个小时。
这时，双十一当天，用户正在疯狂购物，三个小时过去了，首页的redis缓存全部失效，这个时候redis中查询不到数据，那么只能去数据库中查询，数据库承受不住压力，导致数据库宕机（挂掉）。
常见缓存雪崩出现原因：
1.redis服务器挂掉了。
2.对缓存数据设置了相同的过期时间，导致某时间段内缓存集中失效。
解决方案：
1.设置随机缓存失效时间，让他不要在同一时间失效。在设置缓存的时候，要随机初始化它的缓存失效时间，不让缓存在同一时间全部失效（为什么要设置缓存失效时间呢？因为你如果缓存长时间不失效，你缓存的数据和真实的数据有延迟性）。
2.redis一般都是集群部署，把热点的key放到不同的节点上去，让这些热点的key平均的分布在不同的redis库上。
3.不设置缓存失效的时间（不推荐，你缓存的数据和数据库的数据有延迟行，可能两者的数据不一致）。
4.跑定时任务，在缓存失效前刷进新的缓存。
二、缓存穿透
缓存穿透：缓存穿透是指key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。 常见案例： 比如用一个不存在的用户id(id=-1)获取用户信息，缓存中没有这样的数据，这时候就穿透redis，直接打到了数据库上，若黑客利用此漏洞进行攻击可能压垮数据库。解决方案：
1.数据库无论查出什么结果，都缓存到redis里，这样他下次发同样的参数的时候就不会穿透到redis。但是他可能会换不同的参数。
2.把恶意用户的ip拉黑。
3.对参数的合法性进行校验。判断参数，如果不合法，直接return掉。
4.使用布隆过滤器。将所有可能存在的数据哈希到一个足够大的bitmap（位图）中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
三、缓存击穿
缓存击穿：缓存击穿是指一个非常热点的key，大量用户去请求这个热点key，这个缓存key突然失效（过期）的时候，这些请求都会打到数据库上并回设到缓存，这个时候大并发的请求可能会瞬间把数据库压垮。常见案例：
双十一期间，拍卖一件商品，将该商品的信息缓存到redis中，并设置了三小时的失效时间，但是时间过了三个小时，还没有竞拍结束，这时候缓存失效，导致该key的大量请求打到了数据库，导致数据库挂掉了，服务器无法响应。
解决方案：
1.缓存不过期（不推荐）。
2.分布式锁：首先大量的用户去访问这个redis请求数据，如果有的话就返回给用户，如果redis里没有这个数据，他就去数据库请求数据，我们就在请求数据库这一步给他上上锁，这时候只有一个线程能抢到这个锁，所以也就只有一个线程能操作这个数据库，这个线程查到数据后，再重新缓存到redis里，其他没抢到锁的线程先睡几毫秒，然后再重新去redis里查询。这时候，其他线程去访问redis，这时候redis里已经有数据了，不用再去数据库里查询数据了。也就不用再去竞争分布式锁。直接在redis这一步就返回了。