一 总结
1，原因及解决办法
① 缓存穿透：大量请求根本不存在的key（下文详解）
② 缓存雪崩：redis中大量key集体过期（下文详解）
③ 缓存击穿：redis中一个热点key过期（大量用户访问该热点key，但是热点key过期）
穿透解决方案：
对空值进行缓存
设置白名单
使用布隆过滤器
雪崩解决方案：
进行预先的热门词汇的设置，进行key时长的调整
实时调整，监控哪些数据是热门数据，实时的调整key的过期时长
使用锁机制
击穿解决方案：
进行预先的热门词汇的设置，进行key时长的调整
实时调整，监控哪些数据是热门数据，实时的调整key的过期时长
使用锁机制(只有一个线程可以进行热点数据的重构)
2，三者出现的根本原因
三者出现的根本原因：Redis命中率下降，请求直接打在DB上
2.1 redis正常情况
正常情况下，大量的资源请求都会被redis响应，在redis得不到响应的小部分请求才会去请求DB，这样DB的压力是非常小的，是可以正常工作的（如下图）
2.2 非正常情况
如果大量的请求在redis上得不到响应，那么就会导致这些请求会直接去访问DB，导致DB的压力瞬间变大而卡死或者宕机。如下图：
① 大量的高并发的请求打在redis上
② 这些请求发现redis上并没有需要请求的资源，redis命中率降低
③ 因此这些大量的高并发请求转向DB（数据库服务器）请求对应的资源
④ DB压力瞬间增大，直接将DB打垮，进而引发一系列“灾害”
3， 三者区别
| 问题名称 | 缓存穿透 | 缓存击穿 | 缓存雪崩 |
| 资源是否存在DB数据库服务器中 | × | √ | √ |
| 资源是否存在Redis中 | × | × | × |
| redis没有对应资源的原因 | 根本不存在该资源（DB也没有） | 某个热点key过期 | 大部分key集体过期 |
| 根本原因 | 大量的高并发的请求打在Redis上，但是发现Redis中并没有请求的数据，redis的命令率降低，所以这些请求就只能直接打在DB（数据库服务器）上，在大量的高并发的请求下就会导致DB直接卡死、宕机 | ||
二 缓存
1，问题描述
key 对应的数据在数据源并不存在，每次针对此 key 的请求从缓存获取不到，请求都会压到数据源（数据库），从而可能压垮数据源。
举例（情景在线）：客户端发送大量的不可响应的请求（如下图）
2,缓存穿透发生的条件
应用服务器压力变大
redis 命中率降低
一直查询数据库，使得数据库压力太大而压垮
其实 redis 在这个过程中一直平稳运行，崩溃的是我们的数据库（如 MySQL）。
3,缓存穿透发生的原因
非正常用户频繁进行很多非正常的 url 访问，使得 redis 查询不到数据库。
4,解决方案
4.1 对空值缓存
如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
4.2 设置可访问的名单（白名单）
使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。
4.3 采用布隆过滤器
布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量 (位图) 和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
4.4 进行实时监控
当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。
5, 注意事项
①使用空值作为缓存的时候，key设置的过期时间不能太长，防止占用太多redis资源
②对空值缓存是一种被动的防御方式，当遇到黑客暴力请求很多不存在的数据就需要写入大量的null值到Redis中，可能导致Redis内存占用不足的情况
③使用布隆过滤器，可以在用户访问的时候判断该资源是否存在，不存在则直接拒绝访问
④布隆过滤器是有一定的误差，所以一般需要配合一些接口流量的限制（规定用户在一段时间内访问的频率）、权限校验、黑名单等来解决缓存穿透的问题
三 缓存击穿
1，问题描述
key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。
2，缓存击穿的现象：
数据库访问压力瞬时增加，数据库崩溃
redis 里面没有出现大量 key 过期
redis 正常运行
3，缓存击穿发生的原因
redis 某个 key 过期了，大量访问使用这个 key（热门 key）
4，解决方案
① 预先设置热门数据：在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长。
② 实时调整：现场监控哪些数据热门，实时调整 key 的过期时长。
③ 使用锁：
就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db。
先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX）去 set 一个 mutex key。
当操作返回成功时，再进行 load db 的操作，并回设缓存，最后删除 mutex key；
当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法。
四 缓存雪崩
1，问题描述
key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。
缓存雪崩与缓存击穿的区别在于这里针对很多 key 缓存，前者则是某一个 key 正常访问。
2，解决方案
① 构建多级缓存架构：nginx 缓存 + redis 缓存 + 其他缓存（ehcache 等）。
② 使用锁或队列：用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，该方法不适用高并发情况。
③ 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。
④ 将缓存失效时间分散开：比如可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
