面试官：你知道缓存击穿、缓存穿透、缓存雪崩吗？
面试题剖析
花里胡哨的名词
刚开始我以为“缓存击穿、缓存穿透、缓存雪崩”说的是3个问题，在各个博客以及视频的讲解下越来越绕。最后我捋了一下，这TM不是一个问题吗。
为了让大家也绕一绕，我把各博客对“缓存击穿、缓存穿透、缓存雪崩”的描述贴在这里：
缓存击穿是指一个热点的Key在某个瞬间过期失效了，大量的并发请求在缓存获取不到数据后直接请求数据库的现象。
缓存穿透是指查询一个根本不存在的数据，缓存和数据库都不会命中，导致每次请求都要到数据库去查询。
缓存雪崩指的是缓存由于宕机或者某些原因不能提供服务，导致所有的请求去访问数据库，造成数据库查询压力骤增从而宕机。
透过现象看本质
我就非常不理解了，为什么把缓存带来的一个问题分好几个场景去描述，还这解决方案，那解决方案的，花里胡哨的增加了大家的理解难度。
在我看来“缓存击穿、缓存穿透，缓存雪崩”都是在说一个问题，那就是：
缓存没命中，请求落到数据库了
而“缓存雪崩”才突出了问题的本质：
没有缓存的缓冲，数据库承受不了那么大的压力，可能会造成宕机等问题。
仔细想想是不是这样？“缓存击穿、缓存穿透、缓存雪崩”最终的描述都是请求落到数据库了，只不过场景不同罢了。但不论哪种场景，在并发高的情况下都会给数据库带来压力。
所以，一个问题分这么多场景，引出这么多名词，我认为就是在增加大家的理解难度。
面试题解决方案
有问题就会有解决方案，既然看了这篇文章就不要死记硬背了，不然过段时间又会忘记，跟着思路顺其自然的理解。
透过现象看本质
对于以上的几个场景，要解决的问题就是：
如何提高缓存命中率。
也就是尽量避免请求打到数据库中，尤其是高并发的请求。主要涉及两个层面：
- 缓存组件要可靠：首先要确保缓存组件足够可靠。
- 代码逻辑要严谨：在编写代码使用缓存时尽量要把各种场景考虑进去，把问题当作功能的一部分。
像“缓存击穿、缓存穿透”问题的产生都属于代码逻辑不严谨。热点Key怎么能突然消失呢？一个相同的请求怎么能并发访问到数据库呢？怎么能允许一个不存在的数据一直请求呢？这些问题在我看来都是不应该发生的。
接下来就针对引起“缓存击穿、缓存穿透、缓存雪崩”的几个问题进行剖析解决。
提高缓存命中率一：完美处理热点Key的消失
热点数据通常分为可控和不可控。拿电商系统来讲，商品分类属于可控，因为基本上这类数据是通过后台配置的。而一些商品可能会因为某个原因突然爆火成为热点数据，这类数据属于不可控。
不论可控或不可控，热点数据不可以突然就消失，所以在缓存时要有对应的策略。
- 像商品分类这类数据就可以不设置过期时间。
- 而像不可控的热点数据，要靠一些策略避免其过期，比如通过“看门狗”方式监控热点Key，快过期时进行“续命”。
可以都不设置过期时间，让淘汰策略去淘汰数据吗？
非常不建议。
之前生产环境曾遇到过一个问题:用户每次登录之后会莫名其妙退出。经过排查发现，原来是因为Redis服务容量不足，所以最近登录生成的token一直被淘汰。
虽然没有报错，但是给用户带来不好的体验，对产品造成非常不好的影响。
当然，避免不了热点Key被人为删除或者其他恶意破坏，当发生这种情况怎么办？
如果热点Key不存在缓存中，势必要去数据库中查询了。此时，如果并发请求过高，一定不能让所有请求打到数据库，可以对该key进行加锁处理，获取到锁的请求去数据库访问并缓存，其他请求则等待该key缓存后再访问缓存。
因为平时写代码会很自然考虑到这一点，所以这也是为什么我刚开始一直不理解“缓存击穿”这样的问题。
提高缓存命中率二：避免查询不存在的数据
造成“查询不存在的数据”的原因要么是代码或数据出现问题，要么是遭到恶意的攻击造成的空命中。总之，这种情况无法完全避免。
但是，我们知道哪些数据会被缓存。这样的话，我们可以将这些数据放在一个“大集合”中，当请求的数据不存在这个“大集合”时，直接返回NULL即可。
那么问题来了：这个“大集合”放在哪里？肯定不能是数据库，但是内存容量又是有限的。怎么办？
有一个叫布隆过滤器的数据结构可以解决这个问题。其主要用于检测一个元素是否在一个集合里，其原理是：数据通过一组哈希函数映射到位图中，不论该元素多大都只需要占用1位，从而节省大量空间。如下图
布隆过滤器原理
这样的话，我就可以将要缓存的数据先放在布隆过滤器中，当查询的数据不在布隆过滤器时就可以直接返回NULL了。
感兴趣的可以看下 面试官：如何在海量数据中快速检测某个数据
提高缓存命中率三：降低缓存服务的不可用
降低缓存服务的不可用也就是提高缓存服务的可用性，也就是Redis的高可用，这个没有什么逻辑就不展开了。
面试题案例
模拟案例
现在，通过代码模拟一个因“缓存击穿、缓存穿透、缓存雪崩”，请求并发到MySQL服务上，看会发生什么事。
服务器环境：1核1G
编程语言：Java
案例代码
public class MainTest {
private static final String DB_URL = "jdbc:mysql://127.0.0.1:3306/test";
private static final String USER = "root";
private static final String PASS = "Mysql123.";
public static void main(String[] args) throws InterruptedException {
Timer timer = new Timer();
TimerTask task = new TimerTask() {
@Override
public void run() {
QueryTask.cacheExist = false;
}
};
timer.schedule(task, 60 * 1000);
while (true) {
ExecutorService executorService = Executors.newFixedThreadPool(1500);
for (int i = 0; i <1500 ; i++) {
executorService.submit(new MainTest.QueryTask());
System.gc();
}
}
}
static class QueryTask implements Runnable {
static boolean cacheExist = true;
@Override
public void run() {
try {
if (cacheExist) {
System.out.println("访问缓存");
} else {
Class.forName("com.mysql.jdbc.Driver");
Connection conn = DriverManager.getConnection(DB_URL, USER, PASS);
Statement statement = conn.createStatement();
Thread.sleep(3000);
String query = "SELECT * FROM test_cache";
ResultSet rs = statement.executeQuery(query);
while (rs.next()) {
int id = rs.getInt("id");
String value = rs.getString("value");
System.out.println("ID: " + id + ", Value: " + value);
}
rs.close();
statement.close();
conn.close();
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
}上面的代码主要做了两件事：
- 模拟1500个线程去查询数据。cacheExist为true时访问缓存，为false时去请求数据库。
- 通过定时任务在1分钟后将cacheExist设置为false。各位就想象成热点Key的突然消失、查询不存在的数据、redis的宕机。
案例执行效果
代码在执行1分钟后就会报下面的错误信息：
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Data source rejected establishment of connection, message from server: "Too many connections"这是因为MySQL最大连接数只有151，远远低于并发线程数1500。
mysql> show variables like '%max_connections%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 151 |
+-----------------+-------+此时，我将MySQL最大连接数设置为1500。
mysql> SET GLOBAL max_connections = 1500;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like '%max_connections%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 1500 |
+-----------------+-------+现在执行 SHOW STATUS LIKE 'Threads_connected' 去查看MySQL连接线程数会发现数值突然升高，当连接数为1283 左右时，就会发现MySQL服务已经断开连接或者服务器宕机，也就是缓存雪崩的效果。
图片
MySQL压力过高宕机
总结
面试时不要被花里胡哨的问题迷惑住，要思考一下问题的本质。
“缓存击穿、缓存穿透、缓存雪崩”问题的本质就是：
当缓存没命中或失效，并发的请求打到数据库怎么办？
通过上面的描述，此类问题要有以下考虑：
- 提高缓存命中率。比如，要解决热点Key的突然消失、要避免查询不存在的数据等。
- 数据库并发请求要设置合理。太低了浪费资源，太高了就会出现MySQL服务宕机情况。
本文转载自微信公众号「Hi程序员」，可以通过以下二维码关注。转载本文请联系Hi程序员公众号。
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
