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

缓存穿透：

• 啥问题： 请求一个缓存和数据库都不存在的数据，比如GET /user?id=99999999，导致每次请求都会穿透到DB数据库。
• 导致了啥情况： 这种请求体量还比较大，一般可能是恶意请求，导致缓存无法命中，大量的请求DB还扛不住，DB直接宕机。
• 解决方案：可以直接在缓存中存储上这个key，并且value设置为空值，这样请求就不会打到DB。可以在请求直接找Redis之前，先通过布隆过滤器查询一下数据是否存在，存在再去Redis里查询。（但是可能存在误判问题，延伸到布隆过滤器的细节）可以在网关处查看非人类行为的请求，可以直接封掉IP。可以在网关处，查看请求携带的参数是否符合要求，不符合，直接返回空值。
• 实际解决方案： 四个都上！

缓存击穿：

• 啥问题： 一个高并发访问的热点key，在Redis中缓存失效了，大量的请求直接干到DB。
• 导致了啥情况： 热点key过期，Redis查询不到，导致请求干到DB，DB懵逼。
• 解决方案：加锁：可以JVM锁，也可以分布式锁，只要可以限制别有大量的请求直接干到DB就可以。key不过期：针对一些key，无时无刻都在用，那倒不如直接不过期。要考虑好内存问题。
• 实际方式： 方便一些的话，@Cacheable这种Spring-Cache的注解，自带JVM锁，或者根据业务，永不过期也没毛病。
• 免责声明，同学们的套路，个人不太认可：（不是老郑说的！咱们同学们说的） 二级缓存：JVM缓存嘛，JVM缓存到期了，恰巧，Redis缓存也到期，直接全崩。。。。（不是老郑说的！咱们同学们说的） 集群：即便是集群，key的分区基本也是固定的，Cluster没有办法解决缓存击穿的问题，因为缓存击穿是绕过Redis，直接达到DB，你上集群也没办法啊。。。

缓存雪崩：

• 啥问题： 一般服务在启动时，会做缓存预热，导致大量的key生存时间都是一样的，在同一时间都集体失效，导致很多请求绕过了缓存，直接打到DB。
• 导致啥问题： 虽然不是热点key，但是组合拳把DB干懵。
• 解决方案：加锁：可以JVM锁，也可以分布式锁，只要可以限制别有大量的请求直接干到DB就可以。过期时间添加随机数，规避掉这种统一时间到期的问题。也可以针对一些查询及其频繁，更改及其少的key，并且内存不大的，不设置过期时间。
• 实际方案： 三管齐下，都上。