先理解概念：【注：我们这里说的是分布式、高并发环境】
一、缓存穿透是什么？
缓存穿透是指：请求【可以有很多】的数据在缓存、关系型数据库中都不存在，每次来查询都会查询到关系型数据库中。
解决方案：
1、将空对象缓存到Redis：
简单的说就是第一次如果去关系型数据库查询回来如果为空，就将将空值也缓存到Redis（如：set keyxxx null），可以将过期时间设置短一点，避免大量的null值占用内存，如遇到key值饱和攻击将会是很大的麻烦，内存会被这些空值大量占用。
优点：实现简单。
缺点：不存在的key-value占用内存；高并发环境多个线程同时访问，可能存在缓存过期前或者刷缓存前查询都为空，返回不了真实数据。
2、使用布隆过滤器
所谓布隆过滤器就是一个很大的bitmap，由二进制向量表和一系列随机映射函数组成。里面并不存放真实的数据，里面只是标识位（0/1），某个key在hash过后来查不用过滤器返回为0就表示数据库不存在该数据，直接给请求返回为空就行，有值就是1，然后就可以查询缓存服务器，或者去查关系型数据库了。实现方案（redisson+redis，redisson本来就封装好了布隆过滤器、guava、fpp都可以）。
------------------->>>> redisson方案：
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson-spring-boot-starter</artifactId>
<version>3.13.0</version>
</dependency>
</dependencies>
------------------->>>> guava方案：
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>29.0-jre</version>
</dependency>
优点：布隆过滤器内存占用较少；
缺点：实现相对复杂一丢丢、布隆过滤器存在误判【原因是hash冲突，如果key的hash值相同，就会引起本来没值的key判断成了有值，去查Redis或者MySQL】。
二、缓存击穿是什么？
缓存击穿：指一个被高并发访问且缓存重建业务较复杂的key突然失效了，无数查询这个key的请求瞬间会直接打在关系型数据库上，给数据库带来了巨大的压力，通常也叫热点Key问题。
解决方案：
1、互斥锁
高并发环境，避免缓存不存在这个key的数据，然后多个线程并发的去访问数据库，我们需要在查询缓存结束，没有数据后，在查询数据库前需要设置一道分布式锁，拿到锁的才可以执行后续逻辑，拿不到的可以让他等待一段时间重试缓存是否有数据，这里不能重试查询关系型数据库哦【这里锁的设置需要考虑：锁的可重入、可重试、锁的超时释放、锁的主从一致性】。
2、逻辑过期
key的失效多数是由于到了过期时间的key被清理，而新的该key的缓存还没建立，而此时来了大量请求，那我们是不是可以：设置该key不主动失效、分布式锁解决。
a、key不主动失效,不是不主动失效，可以利用Redis的hash结构将过期时间拼接在value里面（如：hset product_01 1000 timestamp ）,用户自己去决定这个key是否过期删除，类似于Redis的key的惰性删除原理，如果有请求过来，查询该key时候，会有一次检查过期时间的操作，如果过期了就先加锁，暂时阻塞其他线程访问数据库，然后删除该缓存，接着再请求数据库写入缓存，释放锁【只能删除自己的锁】，返回数据，其他线程可以查询缓存返回数据库了。这里有可能存在极端情况就是在更新缓存期间，其他线程等待时间过长，直接返回空数据回去。这里也可以考虑MQ异步的去更新缓存哦。
三、缓存雪崩
缓存雪崩：是指同一时段内缓存中大量的key同时失效或者缓存服务器宕机，导致大量请求打在关系型数据库上，关系型数据库有可能瞬间被打死。【通常8c16g的mysql数据库，单台主库2000次/s并发写是可以扛住的，从库8c16g可以达到5000多qps】
解决方案：
1、key同时段失效的情况：
a、 给key的过期时间设置随机值，比如说选择：60s~600s，随机一个数字为过期时间。
b、多级缓存，然后设置不同的过期时间；
c、结合网关、hystrix/sentinel 限流，大批量的请求不用全都放过来，可以允许一部分请求一次失败，让客户重试，比如：抢购、抢红包；
d、结合MQ，请求直接先放到MQ里面，异步的查询Redis或者关系型数据库，异步返回数据，消费者慢慢消费，几乎也都可以做到毫秒或者秒级的返回，高并发的环境，一般用户等待个几秒钟都是可以接受的，不用追求极致，也需要在成本、用户体验、性能、可用性之间做个平衡，作为架构师应该要考虑到这些问题。
2、缓存服务器宕机的情况
这个要尽可能的实现缓存服务的高可用了，不管是缓存的：主从+哨兵、分片+主从+哨兵、集群（一致性hash结构/避免hash倾斜的增加虚拟节点的结构）+哨兵+主从等结构，都可以。注意：主从节点一般都是至少三个节点，且最好是奇数个节点，避免集群选举出现脑裂或者票数一半一半，选不出来，qurom=半数节点以上，majority=存活实例数/2+1。
