面试官:你知道缓存击穿、缓存穿透、缓存雪崩吗?

开发 前端
现在执行 SHOW STATUS LIKE 'Threads_connected'​ 去查看MySQL连接线程数会发现数值突然升高,当连接数为1283 左右时,就会发现MySQL服务已经断开连接或者服务器宕机,也就是缓存雪崩的效果。

前言

又到了一年一度的金三银四了,大家在面试的时候一定被问到过Redis缓存问题吧。可能有些初学者对“缓存击穿、缓存穿透、缓存雪崩”这几个名词感到陌生,或者了解过但是一时半会没办法理解。没关系,希望通过本文可以让你轻松理解这些概念并掌握其解决方案,然后在即将到来的金三银四面试中对你有所帮助。

面试题剖析

花里胡哨的名词

刚开始我以为“缓存击穿、缓存穿透、缓存雪崩”说的是3个问题,在各个博客以及视频的讲解下越来越绕。最后我捋了一下,这TM不是一个问题吗。

为了让大家也绕一绕,我把各博客对“缓存击穿、缓存穿透、缓存雪崩”的描述贴在这里:

缓存击穿是指一个热点的Key在某个瞬间过期失效了,大量的并发请求在缓存获取不到数据后直接请求数据库的现象。

缓存穿透是指查询一个根本不存在的数据,缓存和数据库都不会命中,导致每次请求都要到数据库去查询。

缓存雪崩指的是缓存由于宕机或者某些原因不能提供服务,导致所有的请求去访问数据库,造成数据库查询压力骤增从而宕机。

透过现象看本质

我就非常不理解了,为什么把缓存带来的一个问题分好几个场景去描述,还这解决方案,那解决方案的,花里胡哨的增加了大家的理解难度。

在我看来“缓存击穿、缓存穿透,缓存雪崩”都是在说一个问题,那就是:

缓存没命中,请求落到数据库了

而“缓存雪崩”才突出了问题的本质:

没有缓存的缓冲,数据库承受不了那么大的压力,可能会造成宕机等问题。

仔细想想是不是这样?“缓存击穿、缓存穿透、缓存雪崩”最终的描述都是请求落到数据库了,只不过场景不同罢了。但不论哪种场景,在并发高的情况下都会给数据库带来压力。

所以,一个问题分这么多场景,引出这么多名词,我认为就是在增加大家的理解难度。

面试题解决方案

有问题就会有解决方案,既然看了这篇文章就不要死记硬背了,不然过段时间又会忘记,跟着思路顺其自然的理解。

透过现象看本质

对于以上的几个场景,要解决的问题就是:

如何提高缓存命中率。

也就是尽量避免请求打到数据库中,尤其是高并发的请求。主要涉及两个层面:

  1. 缓存组件要可靠:首先要确保缓存组件足够可靠。
  2. 代码逻辑要严谨:在编写代码使用缓存时尽量要把各种场景考虑进去,把问题当作功能的一部分。

像“缓存击穿、缓存穿透”问题的产生都属于代码逻辑不严谨。热点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();
            }
        }
    }
}

上面的代码主要做了两件事:

  1. 模拟1500个线程去查询数据。cacheExist为true时访问缓存,为false时去请求数据库。
  2. 通过定时任务在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压力过高宕机

总结

面试时不要被花里胡哨的问题迷惑住,要思考一下问题的本质。

“缓存击穿、缓存穿透、缓存雪崩”问题的本质就是:

当缓存没命中或失效,并发的请求打到数据库怎么办?

通过上面的描述,此类问题要有以下考虑:

  1. 提高缓存命中率。比如,要解决热点Key的突然消失、要避免查询不存在的数据等。
  2. 数据库并发请求要设置合理。太低了浪费资源,太高了就会出现MySQL服务宕机情况。

本文转载自微信公众号「Hi程序员」,可以通过以下二维码关注。转载本文请联系Hi程序员公众号。

责任编辑:武晓燕 来源: Hi程序员
相关推荐

2023-12-06 13:38:00

Redis缓存穿透缓存击穿

2021-06-05 09:01:01

Redis缓存雪崩缓存穿透

2019-10-12 14:19:05

Redis数据库缓存

2023-03-10 13:33:00

缓存穿透缓存击穿缓存雪崩

2019-11-05 14:24:31

缓存雪崩框架

2020-03-16 14:57:24

Redis面试雪崩

2020-09-14 06:57:30

缓存穿透雪崩

2022-05-27 07:57:20

缓存穿透缓存雪崩缓存击穿

2022-03-08 00:07:51

缓存雪崩数据库

2023-11-10 14:58:03

2021-12-25 22:28:27

缓存穿透缓存击穿缓存雪崩

2022-07-11 07:36:36

缓存缓存雪崩缓存击穿

2022-11-18 14:34:28

2023-04-14 07:34:19

2020-10-13 07:44:40

缓存雪崩 穿透

2020-10-23 10:46:03

缓存雪崩击穿

2020-03-05 09:09:18

缓存原因方案

2020-12-28 12:37:36

缓存击穿穿透

2024-04-18 11:43:28

缓存数据库Redis

2024-04-07 00:00:02

Redis雪崩缓存
点赞
收藏

51CTO技术栈公众号