项目中业务数据基本上都是存在关系型数据库中，如：mysql，oracle，sqlServer等数据库，项目上线初期，由于用户规模还比较小，系统访问量不大。关系性数据库可以抗住并发较小的请求。随着业务的增长用户的增加系统整体的并发请求增大。关系型数据库处理能力跟不上，在对数据库做主从读写分离，分布式设计之前，引入缓存可以有效提高系统整体的并发。如：redis非关系型数据库。但是在使用缓存redis的时候也存在相应的问题：缓存穿透，击穿，雪崩，如果不注意会导致并发压力绕过缓存直接落在数据库上导致数据库阻塞，崩溃等问题。
1.redis缓存穿透，击穿，雪崩概念
-
缓存穿透：
key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。 -
缓存击穿：
key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。 -
缓存雪崩：
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
2.缓存穿透
故障描述：
缓存与数据库都没有的数据，发起大量访问请求，对后端造成很大的压力。要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
解决方案：
1. 缓存层缓存空值
-缓存太多空值，占用更多空间。（优化：给个空值过期时间）
-存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存把值进去）
//伪代码
public object GetProductListNew() {
int cacheTime = 30;
String cacheKey = "product_list";
String cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) {
return cacheValue;
}
cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) {
return cacheValue;
} else {
//数据库查询不到，为空
cacheValue = GetProductListFromDB();
if (cacheValue == null) {
//如果发现为空，设置个默认值，也缓存起来
cacheValue = string.Empty;
}
CacheHelper.Add(cacheKey, cacheValue, cacheTime);
return cacheValue;
}
}
2. 布隆过滤器
-将数据库中所有的查询条件，放到布隆过滤器中。当一个查询请求来临的时候，先经过布隆过滤器进行检查，如果请求存在这个条件中，那么继续执行，如果不在，直接丢弃。
3. 接口参数验签
过滤掉特殊值，比如id= -1
3.缓存击穿
故障描述：热点单个key，过期，此时迎来高并发
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。
场景一：微博上，某某明星传绯闻，两个明星主页被刷爆
缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
解决方案：
- 使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。
public String get(key) {
String value = redis.get(key);
if (value == null) { //代表缓存值过期
//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); //重试
}
}
else {
return value;
}
}
-
"提前"使用互斥锁(mutex key)：
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。 -
"永远不过期"：这里的“永远不过期”包含两层意思：
从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期。 -
资源保护：
采用netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可。 -
为即将过期的key，续命：
缓存中取值，发现即将过期，追加一个小的时间值，延长有效期。 -
限流：
比如说使用消息队列，让流量在消息队列中囤积下，逐个消费，缓解后端压力。
4.缓存雪崩
故障描述：缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。（与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key）
场景一：同一时间点，缓存全部失效：
比如：有的电商网站在项目重启时，将全部商品信息加入缓存中，并设置等长的有效期。到某一时间点，缓存有效期过期，大量缓存失效，如果遇上高并发，请求全部打在后端数据库上。
场景二：穿透诱发雪崩：
短时间内大量的请求无法命中缓存，请求穿透到数据库，导致数据库繁忙，请求超时。大量的请求超时还会引发更多的重试请求，更多的重试请求让数据库更加繁忙，这样恶性循环导致系统雪崩。
解决方案：
-
设置缓存超时时间的时候加上一个随机的时间长度：
比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟，酱紫可从一定程度上避免雪崩问题。 -
热点数据永不过期，数据库更新时同步更新缓存 （如：电商首页信息）
-
互斥锁排队
根据key获取value值为空时，锁上，从数据库中load数据后再释放锁。若其它线程获取锁失败，则等待一段时间后重试。这里要注意，分布式环境中要使用分布式锁（Redisson），单机的话用普通的锁（synchronized、Lock）。 -
设置过期标志更新缓存
//伪代码
public object GetProductListNew() {
int cacheTime = 30;
String cacheKey = "product_list";
//缓存标记
String cacheSign = cacheKey + "_sign";
String sign = CacheHelper.Get(cacheSign);
//获取缓存值
String cacheValue = CacheHelper.Get(cacheKey);
if (sign != null) {
return cacheValue; //未过期，直接返回
} else {
CacheHelper.Add(cacheSign, "1", cacheTime);
ThreadPool.QueueUserWorkItem((arg) -> {
//这里一般是 sql查询数据
cacheValue = GetProductListFromDB();
//日期设缓存时间的2倍，用于脏读
CacheHelper.Add(cacheKey, cacheValue, cacheTime * 2);
});
return cacheValue;
}
}
参考：https://www.jianshu.com/p/44d4bc0a9f10
参考：https://www.cnblogs.com/xichji/p/11286443.html