Redis充当缓存：
一、缓存穿透：(要查询的数据根本不存在)
根本原因：请求根本不存在的资源
举例：客户端发送大量的不可响应的请求
当大量的客户端发送大量的不可响应的请求 ，就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有该请求的数据，所以Redis也没有对应的数据，那么这些请求在redis就得不到响应，就会直接打在DB上，导致DB压力过大而卡死情景在线或宕机
解决方案：
(1)对空值进行缓存
类似于上面的例子，虽然数据库中没有该请求的数据，但是在redis中对他进行缓存（key=xxx，value=null），这样当请求到达redis的时候就会直接返回一个null的值给客户端，避免了大量无法访问的数据直接打在DB上。
(2)实时监控
对redis进行实时监控，当发现redis中的命中率下降的时候进行原因的排查，配合运维人员对访问对象和访问数据进行分析查询，从而进行黑名单的设置限制服务。
(3)使用Boolean过滤器
使用BitMap作为布隆过滤器，将目前所有可以访问到的资源通过简单的映射关系放入到布隆过滤器中（哈希计算），当一个请求来临的时候先进行布隆过滤器的判断，如果有那么才进行放行，否则就直接拦截。
(4)接口校验
类似于用户权限的拦截，对于无效访问就直接拦截，不允许这些请求到达Redis、DB上。
二、缓存雪崩
**产生的原因：**redis中大量的key集体过期
举例：当redis中的大量key集体过期，可以理解为redis中的大部分数据都被清空了（失效了），那么这时候如果有大量并发的请求来到，那么redis就无法进行有效的响应（命中率急剧下降），请求就都打到DB上了，到时DB直接崩溃。
解决方案：
使用互斥锁（Mutex Lock）或分布式锁，只允许一个请求去访问后端数据源，其他请求等待并共享结果。（推荐使用）
将失效时间分散开, 通过使用自动生成随机数使得key的过期时间是随机的，防止集体过期
使用多级架构,使用nginx缓存+redis缓存+其他缓存，不同层使用不同的缓存，可靠性更强
设置缓存标记,记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际的key
设置热点数据的永远不过期或过期时间较长，以减少热点数据失效的机会。
三. 缓存击穿
产生的原因：redis中的某个热点key过期，但是此时有大量的用户访问该过期key。
比如：某个热搜很火，这时候大家都在访问该热点事件，但是可能由于某种原因，redis的这个热点key过期了，那么这时候大量高并发对于该key的请求就得不到redis的响应，那么就会将请求直接打在DB服务器上，导致整个DB瘫痪。
解决方案：
为缓存数据设置不同的过期时间，使其在不同时间点过期，避免集中失效。监控数据，适时调整，监控哪些数据是热门数据，实时的调整key的过期时长
引入两级缓存架构，例如使用本地缓存（如Guava Cache）作为第一级缓存，并设置较短的过期时间，Redis作为第二级缓存，并设置较长的过期时间。
针对热点数据，可以提前进行预加载，保证其缓存不会在同一时间全部失效。