如何解决缓存穿透？
作者：程序员马丁
在线博客：https://open8gu.com
大话面试，技术同学面试必备的八股文小册，以精彩回答应对深度问题，助力你在面试中拿个offer。
回答话术
缓存穿透是指由于请求没有办法命中缓存，因此就会直接打到数据库，当请求量较大时，大量的请求就可能会直接把数据库打挂。
通常情况下，缓存是为了提高数据访问速度，避免频繁查询数据库。但如果攻击者故意请求缓存中不存在的数据，就会导致缓存不命中，请求直接访问数据库。
缓存穿透一般有几种解决方案：
1. 空对象值缓存
当查询结果为空时，也将结果进行缓存，但是设置一个较短的过期时间。这样在接下来的一段时间内，如果再次请求相同的数据，就可以直接从缓存中获取，而不是再次访问数据库，可以一定程度上解决缓存穿透问题。
这种方式是比较简单的一种实现方案，会存在一些弊端。那就是当短时间内存在大量恶意请求，缓存系统会存在大量的内存占用。如果要解决这种海量恶意请求带来的内存占用问题，需要搭配一套风控系统，对用户请求缓存不存在数据进行统计，进而封禁用户。整体设计就较为复杂，不推荐使用。
2. 使用锁
当请求发现缓存不存在时，可以使用锁机制来避免多个相同的请求同时访问数据库，只让一个请求去加载数据，其他请求等待。
这种方式可以解决数据库压力过大问题，如果会出现“误杀”现象，那就是如果缓存中不存在但是数据库存在这种情况，也会等待获取锁，用户等待时间过长，不推荐使用。
3. 布隆过滤器
布隆过滤器是一种数据结构，可以用于判断一个元素是否存在于一个集合中。它可以在很大程度上减轻缓存穿透问题，因为它可以快速判断一个数据是否可能存在于缓存中。
这种方式较为推荐，可以将所有存量数据全部放入布隆过滤器，然后如果缓存中不存在数据，紧接着判断布隆过滤器是否存在，如果存在访问数据库请求数据，如果不存在直接返回错误响应即可。
但是这种问题还是会有一些小概率问题，那就是如果使用一种小概率误判的缓存进行攻击，依然会对数据库造成比较大的压力。
4. 布隆过滤器+空对象+分布式锁
上面的这些方案或多或少都会有些问题，应该用三者进行组合用来解决缓存穿透问题。
如果说缓存不存在，那么就通过布隆过滤器进行初步筛选，然后判断是否存在缓存空值，如果存在直接返回失败。如果不存在缓存空值，使用锁机制避免多个相同请求同时访问数据库。最后，如果请求数据库为空，那么将为空的 Key 进行空对象值缓存。
问题详解
以读取用户信息为例，一般来说用户信息都会放到缓存里，正常请求获取缓存，如果存在则返回成功，不存在则去请求数据库重新加载。如果说恶意攻击，那么只需要访问不存在的用户即可，这将导致大量的请求打到数据库上，可能会导致数据库压力过大。
咱们根据实际场景出发，一步一步拆解缓存穿透是如何对应用和数据库造成问题的，以及解决方案代码如何写。
1. 查询缓存不存在请求数据库
第一版，查询数用户据缓存是否存在，不存在的话请求数据库，数据库存在则把当前缓存数据回写到缓存。
问题比较明显，如果用户数据不存在，大量请求就会每一次都请求到数据库，导致数据库压力暴涨。
伪代码如下：
public String selectUser(String userId) {
String cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
String dbData = userMapper.selectId(userId);
if (StrUtil.isNotBlank(dbData)) {
cahce.set(userId, dbData);
cacheData = dbData;
} else {
throw new RuntimeException();
}
}
return cacheData;
}
2. 空对象缓存
访问缓存中不存在后，咱们调用数据库获取数据是否存在，这里只说极端情况，如果不存在，对该值进行缓存空对象。当判断缓存不存在后，先判断是否存在空值，如果存在则直接返回。
伪代码如下：
public String selectUser(String userId) {
String cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
// 判断 Key 是否包含空值缓存，存在直接返回，不存在继续流程
Boolean cacheIsNull = cache.hasKey("is-null_" + userId);
if (cacheIsNull) {
throw new RuntimeException();
}
String dbData = userMapper.selectId(userId);
if (StrUtil.isNotBlank(dbData)) {
cahce.set(userId, dbData);
cacheData = dbData;
} else {
// 查询数据库中不存在数据，添加空值缓存并返回
cache.set("is-null_" + userId, 较短过期时间);
throw new RuntimeException();
}
}
return cacheData;
}
当查询结果为空时，也将结果进行缓存，但是设置一个较短的过期时间。这样在接下来的一段时间内，如果再次请求相同的数据，就可以直接从缓存中获取，而不是再次访问数据库，可以一定程度上解决缓存穿透问题。
这种方式是比较简单的一种实现方案，会存在一些弊端。那就是当短时间内存在大量恶意请求，缓存系统会存在大量的内存占用。如果要解决这种海量恶意请求带来的内存占用问题，需要搭配一套风控系统，对用户请求缓存不存在数据进行统计，进而封禁用户。整体设计就较为复杂，不推荐使用。
3. 使用分布式锁
当请求发现缓存不存在时，可以使用锁机制来避免多个相同的请求同时访问数据库，只让一个请求去加载数据，其他请求等待。
伪代码如下：
public String selectUser(String userId) {
String cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
Lock lock = getLock("业务标识");
lock.lock();
try {
// 拿到锁之后进行双重判定，如果缓存已经存在则直接返回即可
cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
String dbData = userMapper.selectId(userId);
if (StrUtil.isNotBlank(dbData)) {
cahce.set(userId, dbData);
cacheData = dbData;
}
}
} finally {
lock.unlock();
}
}
return cacheData;
}
这种方式可以解决数据库压力过大问题，如果会出现“误杀”现象，那就是如果缓存中不存在但是数据库存在这种情况，也会等待获取锁，用户等待时间过长。
代码中用到了缓存击穿文章中讲到的双重判定锁，不了解的同学可以看看：✅ 如何解决缓存击穿？
为什么锁标识使用“业务标识”而不是具体的 userId？
这么做是因为，如果恶意用户根据大量不重复且不存在的 userId 进行攻击，那么如果说根据 userId 加锁，相当于每个请求都能获取到锁，这个锁也就相当于不存在。所以，这里只能锁业务标识，比如锁的 Key 是 user_info_lock，代表了用户信息查看业务。
锁机制会带来额外的性能开销，算是针对安全问题的一种妥协，一般不建议在生产中单独使用。
4. 布隆过滤器
布隆过滤器是一种数据结构，可以用于判断一个元素是否存在于一个集合中。它可以在很大程度上减轻缓存穿透问题，因为它可以快速判断一个数据是否可能存在于缓存中。
伪代码如下：
public String selectUser(String userId) {
String cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
if (!bloomFilter.contains(fullShortUrl)) {
throw new RuntimeException();
}
String dbData = userMapper.selectId(userId);
if (StrUtil.isNotBlank(dbData)) {
cahce.set(userId, dbData);
cacheData = dbData;
}
}
return cacheData;
}
这种方式较为推荐，可以将所有存量数据全部放入布隆过滤器，然后如果缓存中不存在数据，紧接着判断布隆过滤器是否存在，如果存在访问数据库请求数据，如果不存在直接返回错误响应即可。
但是这种问题还是会有一些小概率问题，那就是如果使用一种小概率误判的缓存进行攻击，依然会对数据库造成比较大的压力。
因为过程中说到了布隆过滤器，属于面试中常问的知识点。如果面试官紧接着问布隆过滤器误判、容量如何判断以及后续如何扩容问题，参考下述链接：
5. 布隆过滤器+空对象+分布式锁
如果说缓存不存在，那么就通过布隆过滤器进行初步筛选，然后判断是否存在缓存空值，如果存在直接返回失败。如果不存在缓存空值，使用锁机制避免多个相同请求同时访问数据库。最后，如果请求数据库为空，那么将为空的 Key 进行空对象值缓存。
伪代码如下：
public String selectUser(String userId) {
String cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
// 判断 Key 是否存在布隆过滤器，存在则继续流程，否则直接返回
if (!bloomFilter.contains(fullShortUrl)) {
throw new RuntimeException();
}
// 判断 Key 是否包含空值缓存，存在直接返回，不存在继续流程
Boolean cacheIsNull = cache.hasKey("is-null_" + userId);
if (cacheIsNull) {
throw new RuntimeException();
}
// 获取分布式锁，为什么这里获取业务标识，而不是具体某个 Key？具体见上文分布式锁章节
Lock lock = getLock("业务标识");
lock.lock();
try {
// 拿到锁之后进行双重判定，如果缓存已经存在则直接返回即可
cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
String dbData = userMapper.selectId(userId);
if (StrUtil.isNotBlank(dbData)) {
cahce.set(userId, dbData);
cacheData = dbData;
} else {
// 查询数据库中不存在数据，添加空值缓存并返回
cache.set("is-null_" + userId, 较短过期时间);
throw new RuntimeException();
}
}
} finally {
lock.unlock();
}
}
return cacheData;
}
请求布隆过滤器和缓存空值判断会向 Redis 发起两次网络 IO，如果想优化的话，可以使用管道或者 Lua 命令来提高性能。详情参考：✅ 如何提升 Redis 批量访问性能？
之前我考虑到这就结束了，得益于我开源的 SaaS 短链接项目，有很多细心的同学给我提了一些建议。那就是在获取到锁后，不止对正常缓存双重判定，同时也要对空值缓存对象做双重判定。
public String selectUser(String userId) {
String cacheData = cache.get(userId);
if (StrUtil.isBlank(cacheData)) {
// 判断 Key 是否存在布隆过滤器，存在则继续流程，否则直接返回
if (!bloomFilter.contains(fullShortUrl)) {
throw new RuntimeException();
}
// 判断 Key 是否包含空值缓存，存在直接返回，不存在继续流程
Boolean cacheIsNull = cache.hasKey("is-null_" + userId);
if (cacheIsNull) {
throw new RuntimeException();
}
// 获取分布式锁，为什么这里获取业务标识，而不是具体某个 Key？具体见上文分布式锁章节
Lock lock = getLock("业务标识");
lock.lock();
try {
// 拿到锁之后进行双重判定，如果缓存已经存在则直接返回即可
cacheData = cache.get(userId);
if (StrUtil.isNotBlank(cacheData)) {
return cacheData;
}
// 拿到锁之后进行双重判定，如果空值缓存已经存在则直接终止流程即可
cacheIsNull = cache.hasKey("is-null_" + userId);
if (!cacheIsNull) {
throw new RuntimeException();
}
// 根据用户标识查询数据库记录
String dbData = userMapper.selectId(userId);
if (StrUtil.isNotBlank(dbData)) {
cahce.set(userId, dbData);
cacheData = dbData;
} else {
// 查询数据库中不存在数据，添加空值缓存并返回
cache.set("is-null_" + userId, 较短过期时间);
throw new RuntimeException();
}
} finally {
lock.unlock();
}
}
return cacheData;
}
至此，缓存穿透解决方案完美结束。
上面写得缓存穿透代码思路，只要不出现极端场景，大概率能涵盖 90% 工作当中的业务场景。如果你有好的优化建议或者没有考虑到的场景，欢迎沟通。