谈一谈缓存穿透、缓存击穿和缓存雪崩，以及解决办法

1. 缓存穿透

1）问题：大量并发查询不存在的KEY，在缓存和数据库中都不存在，这样每次都要到缓存和数据库查询，无疑给缓存和数据库增大压力。
原因：一般有两种情况。一、业务数据被误删，导致缓存和数据库中都没有数据。二、恶意进行ddos攻击。
解决思路：为什么会出现多次穿透呢？因为数据库中不存在查询一直为空。只要我们然缓存区分返回数据是不存在，还是查询到空就行了。
解决办法：缓存空值的key，这样即使不存在的话，也会加入到缓存中。

2.缓存击穿

1）问题：某个 KEY 失效的时候，正好有大量并发请求访问这个 KEY。
分析：跟穿透其实很像，属于比较偶然的。
解决办法：KEY 的更新操作添加全局互斥锁。完全以缓存为准，使用延迟异步加载的策略（异步线程负责维护缓存的数据，定期或根据条件触发更新），这样就不会触发更新。

3.缓存雪崩

1）问题：当某一时刻发生大规模的缓存失效的情况，导致大量的请求无法获取数据，从而将 流量压力传导到数据库上，导致数据库压力过大甚至宕机。 2）原因：一般而言，缓存雪崩有 2 种可能性：大量的数据同一个时间失效：比如业务关系 强相关的数据要求同时失效 Redis 宕机
3） 分析：一般来说，由于更新策略、或者数据热点、缓存服务宕机等原因，可能会导致缓存 数据同一个时间点大规模不可用，或者都更新。所以，需要我们的更新策略要在时间上合 适，数据要均匀分享，缓存服务器要多台高可用。
4）解决办法：更新策略在时间上做到比较平均。如果数据需要同一时间失效，可以给这批数 据加上一些随机值，使得这批数据不要在同一个时间过期，降低数据库的压力。使用的热数据尽量分散到不同的机器上。多台机器做主从复制或者多副本，实现高可用。做好主从的部署，当主节点挂掉后，能快速的使用从结点顶上。实现熔断限流机制，对系统进行负载能力控制。对于非核心功能的业务，拒绝其请求，只允许核心功能业务访问数据库获取 数据。服务降价：提供默认返回值，或简单的提示信息。