缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库。

简单的来说,就是请求之后,发现数据不存在,就将null值打入Redis中。
优点:
缺点:
分析:
当请求第一次来时,数据库中没有该数据,数据库向Redis写入一个null;此时正好数据库中被插入了该数据,又有一个请求来访问,但是刚刚向Redis中插入的null来没有过期,就出现了不一致(该请求从Redis拿到的结果就是null,而数据库中其实是有实际数据的)
当然我们也有许多的解决办法,例如:将TTL的时间设置的足够短;每次向数据库新增数据的时候主动将其插入缓存中去覆盖那个null。

在客户端与Redis之间加了一个布隆过滤器,对于请求进行过滤。
布隆过滤器的大致的原理:布隆过滤器中存放二进制位。数据库的数据通过hash算法计算其hash值并存放到布隆过滤器中,之后判断数据是否存在的时候,就是判断该hash值是0还是1。
但是这个玩意是一种概率上的统计,当其判断不存在的时候就一定是不存在;当其判断存在的时候就不一定存在。所以有一定的穿透风险!!!
优点:
缺点:
我一般是采用方案一的方式去实现——缓存空对象
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力。情况大致如下图所示:

操作简单,当我们在做缓存预热的时候,就有可能在同一时间批量插入大量的数据,那么如果它们的TTL都一样的话就可能出现大量key同时过期的情况!!!所以我们需要在设置过期时间TTL的时候,定义一个范围,追加该范围内的一个随机数。
使用集群提高可靠性,后续讲解~~~之后写了会在这里贴上链接。
也是后续的微服务的知识~~~SpringCloud中有提!!!
请求到达浏览器,nginx可以做缓存,未命中找Redis,再未命中找JVM,最后到数据库......
SpringCloud中有多级缓存的实现方案,Redis后期也会提到,之后也会更新。
缓存击穿问题也叫热点Key问题,就是⼀个被高并发访问并且缓存重建业务较复杂的key突然失效了,无数的请求访问会在瞬间给数据库带来巨大的冲击。