面试题剖析
花里胡哨的名词
刚开始我以为“缓存击穿、缓存穿透、缓存雪崩”说的是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程序员公众号。