Redis缓存的雪崩、穿透、击穿

缓存雪崩

-产生原因
我们都知道Redis不可能把所有的数据都缓存起来，所以Redis需要对数据设置过期时间，并采用的是惰性删除（放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，那就返回该键）+定期删除两种策略对过期键删除。如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。这就是缓存雪崩：Redis挂掉了，请求全部走数据库。缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！

• 解决方案
  在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。首先强调的是缓存雪崩对底层系统的冲击非常可怕。

1. 有一个简单处理方案，就是将缓存失效时间分散开，比如我们在原有失效时间上增加一个随机值，如1~5分钟随机，尽量让缓存不要同时失效，从而尽量避免缓存雪崩。
2. 实现高可用架构，尽量避免Redis挂掉的情况。
3. Redis挂掉后采用本地缓存和限流策略，避免DB直接被干掉。
4. Redis持久化，Redis挂掉后，重启后可以自动从磁盘中加载数据，能快速回复数据。

缓存击穿

• 产生原因
  对于一些设置了过期时间的Key，当这些Key在被某些时间点大量高并发访问时，这个时候就需要考虑缓存被“击穿”的问题，这个问题和雪崩区别在于只针对某个Key的缓存，而缓存雪崩是针对多个Key的缓存。简单来说，就是当某个时间点某个Key被高并发访问，此时恰好缓存过期，那么所有请求都落到DB上了，这是瞬时的大并发就有可能导致将DB压垮，这种现象就叫缓存击穿。
• 解决方案

1. 后台刷新：后台定义一个job(定时任务)专门主动更新缓存数据.比如,一个缓存中的数据过期时间是30分钟,那么job每隔29分钟定时刷新数据(将从数据库中查到的数据更新到缓存中)。这种方案比较容易理解，但会增加系统复杂度。比较适合那些 key 相对固定,cache 粒度较大的业务，key 比较分散的则不太适合，实现起来也比较复杂。
2. 检查更新：将缓存key的过期时间(绝对时间)一起保存到缓存中(可以拼接,可以添加新字段,可以采用单独的key保存..不管用什么方式,只要两者建立好关联关系就行).在每次执行get操作后,都将get出来的缓存过期时间与当前系统时间做一个对比,如果缓存过期时间-当前系统时间<=1分钟(自定义的一个值),则主动更新缓存.这样就能保证缓存中的数据始终是最新的(和方案一一样,让数据不过期.)。 这种方案在特殊情况下也会有问题。假设缓存过期时间是12:00，而 11:59到 12:00这 1 分钟时间里恰好没有 get 请求过来，又恰好请求都在 11:30 分的时候高并发过来，那就悲剧了。这种情况比较极端，但并不是没有可能。因为“高并发”也可能是阶段性在某个时间点爆发。
3. 分级缓存：采用 L1 (一级缓存)和 L2(二级缓存) 缓存方式，L1 缓存失效时间短，L2 缓存失效时间长。请求优先从 L1 缓存获取数据，如果 L1缓存未命中则加锁，只有 1 个线程获取到锁,这个线程再从数据库中读取数据并将数据再更新到到 L1 缓存和 L2 缓存中，而其他线程依旧从 L2 缓存获取数据并返回。 这种方式，主要是通过避免缓存同时失效并结合锁机制实现。所以，当数据更新时，只能淘汰 L1 缓存，不能同时将 L1 和 L2 中的缓存同时淘汰。L2 缓存中可能会存在脏数据，需要业务能够容忍这种短时间的不一致。而且，这种方案可能会造成额外的缓存空间浪费。
4. 互斥锁：这种方案是通过异步方式 去获取缓存过程中，其他key 处于等待现象，必须等待第一个构建完缓存之后，释放锁，其他人才能通过该key才能访问数据; 第一个key1 在查询db，获取数据 到放入缓存过程中，都有把锁 先锁住，其他人就必须等待，等待这个人把缓存设置成功，才去释放锁，那其他人就直接从缓存里面取数据；不会造成数据库的读写性能的缺陷;

缓存穿透

• 产生原因
  缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义。请求的数据在缓存大量不命中，导致请求走数据库。
  缓存穿透如果发生了，也可能把我们的数据库搞垮，导致整个服务瘫痪！
• 解决方案

1. 由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！
2. 当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。