面对海量请求,缓存设计还应该考虑哪些问题?

从第一个缓存框架 Memcached 诞生以来,缓存就广泛地存在于互联网应用中。如果你的应用流量很小,那么使用缓存可能并不需要做多余的考虑。但如果你的应用流量达到了成百上千万,那么你就不得不考虑深层次的缓存问题:缓存穿透、缓存击穿与缓存雪崩。

缓存穿透

缓存穿透是指查询一个一定不存在的数据,因为这个数据不存在,所以永远不会被缓存,所以每次请求都会去请求数据库。

例如我们请求一个 UserID 为 -1 的用户数据,因为该用户不存在,所以该请求每次都会去读取数据库。在这种情况下,如果某些心怀不轨的人利用这个存在的漏洞去伪造大量的请求,那么很可能导致DB承受不了那么大的流量就挂掉了。

对于缓存穿透,有几种解决方案,一种是事前预防,一种是事后预防。

事前预防。其实就是对所有请求都进行参数校验,把绝大多数非法的请求抵挡在最外层。在我们举的这个例子中,那么就是做参数校验,对于 UserID 小于 0 的请求全部拒绝。但即使我们做了全面的参数校验,还是可能存在漏网之鱼,会出现一些我们没想到的情况。

例如我们的 UserID 是递增的,那么如果有人请求一个 UserID 很大的用户信息(例如:1000000),而我们的 UserID 最大也就 10000。这个时候,你不可能限制 UserID 大于 1 万的就是非法的,或者说大于 10 万就是非法的,所以该用户ID肯定可以通过参数校验。但该用户确实不存在,所以每次请求都会去请求数据库。

其实上面只是我所能想到的一种情况,我们没想到的情况肯定还有很多。对于这些情况,我们能做的就是时候预防。

事后预防。事后预防说的就是当查询到一个空的结果时,我们仍然将这个空的结果进行缓存,但是设置一个很短的过期时间(例如一分钟)。在这里我们可以看到,其实我们并没有完全预防非法请求,只不过是将非法请求的风险让承受能力更强的redis去承担,让承受能力稍弱的数据库更安全。

通过上面这两种处理方式,我们基本可以解决缓存穿透的问题。事前预防解决80%的非法请求,剩下的20%非法请求则使用Redis转移风险。

缓存击穿

如果你的应用中有一些访问量很高的热点数据,我们一般会将其放在缓存中以提高访问速度。另外,为了保持时效性,我们通常还会设置一个过期时间。但是对于这些访问量很高的KEY,我们需要考虑一个问题:当热点KEY在失效的瞬间,海量的请求会不会产生大量的数据库请求,从而导致数据库崩溃?

例如我们有一个业务 KEY,该 KEY 的并发请求量为 10000。当该 KEY 失效的时候,就会有 1 万个线程会去请求数据库更新缓存。这个时候如果没有采取适当的措施,那么数据库很可能崩溃。

其实上面这个问题就是缓存击穿的问题,它发生在缓存KEY的过期瞬间。对于这种情况,现在常用的解决方式有这么两种:互斥锁、永远不过期。

互斥锁

互斥锁指的是在缓存KEY过期去更新的时候,先让程序去获取锁,只有获取到锁的线程才有资格去更新缓存KEY。其他没有获取到锁的线程则休眠片刻之后再次去获取最新的缓存数据。通过这种方式,同一时刻永远只有一个线程会去读取数据库,这样也就避免了海量数据库请求对于数据库的冲击。

而对于上面说到的锁,我们可以使用缓存提供的一些原则操作来完成。例如对于 redis 缓存来说,我们可以使用其 SETNX 命令来完成。

public String get(key) {  
    String value = redis.get(key);  
    if (value == null) { //缓存过期  
        if (redis.setnx(key_mutex, 1, 1 ** 60) == 1) {   
                value = db.get(key);  
                redis.set(key, value, expireTime);  
                redis.del(key_mutex);  
            } else {  
                //休眠片刻后重试
                sleep(50);  
                get(key);   
            }  
        } else {  
            return value;        
    }  
}

上面的 key_mutex 其实就是一个普通的 KEY-VALUE 值,我们使用 setnx 命令去设置其值为 1。如果这时候已经有人在更新缓存KEY了,那么 setnx 命令会返回 0,表示设置失败。

永远不过期

从缓存的角度来看,如果你设置了永远不过期,那么就不会有海量请求数据库的情形出现。此时我们一般通过新起一个线程的方式去定时将数据库中的数据更新到缓存中,更加成熟的方式是通过定时任务去同步缓存和数据库的数据。

但这种方案会出现数据的延迟问题,也就是线程读取到的数据并不是最新的数据。但对于一般的互联网功能来说,些许的延迟还是能接受的。

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到数据库,最终导致数据库瞬时压力过大而崩溃。

例如我们有 1000 个KEY,而每个 KEY 的并发请求不大,只有 10 次。而缓存雪崩指的就是这 1000 个 KEY 在同一时间,同时失效,这个时候就突然有 1000 ** 10 = 一万次查询。

缓存雪崩导致的问题一般很难排查,如果没有事先预防,很可能要花很大力气才能找得到原因。对于缓存雪崩的情况,最简单的方案就是在原有失效时间的基础上增加一个随机时间(例如1-5分钟),这样每个缓存过期时间的重复率就会降低,从而减少缓存雪崩的发生。

总结

对于缓存穿透、缓存击穿、缓存雪崩这三个情景,许多人会搞不明白,甚至会混淆。

「缓存穿透」指的是请求不存在的数据,从而使得缓存形同虚设,缓存层被穿透了。例如我们请求一个 UserID 为 -1 的用户数据,因为该用户不存在,所以该请求每次都会去读取数据库。在这种情况下,如果某些心怀不轨的人利用这个存在的漏洞去伪造大量的请求,那么很可能导致DB承受不了那么大的流量就挂掉了。

「缓存击穿」指的是并发量很高的 KEY,在该 KEY 失效的瞬间有很多请求同同时去请求数据库,更新缓存。例如我们有一个业务 KEY,该 KEY 的并发请求量为 10000。当该 KEY 失效的时候,就会有 1 万个线程会去请求数据库更新缓存。这个时候如果没有采取适当的措施,那么数据库很可能崩溃。

「缓存雪崩」则是指缓存在同一时间同时过期,就像所有雪块同一时刻掉下来,像雪崩一样。例如我们有 1000 个KEY,而每个 KEY 的并发请求不大,只有 10 次。而缓存雪崩指的就是这 1000 个 KEY 在同一时间,同时失效,这个时候就突然有 1000 ** 10 = 一万次查询。

对于它们出现的情形,我们可以做一些总结:

「缓存穿透」是业务层面的漏洞导致非法请求,与请求量、缓存失效没关系。「缓存击穿」则只会出现在热点数据上,发生在缓存失效的瞬间,与业务没多大关系。「缓存雪崩」则是因为多个 KEY 同时失效,导致数据库请求太多。非热点数据也会导致缓存雪崩,只要同时失效的 KEY 足够多。

原文发布于微信公众号 - Linyb极客之路(gh_c420b2cf6b47)

原文发表时间:2018-05-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Crossin的编程教室

【Python 第64课】python shell

各位好久不见,我终于又更新了:D。今天抽空来讲点非常非常基础的东西,关于在哪里写 python。 如果你已经编写过自己的程序,相信对这些内容已经熟悉。但很多刚刚...

360100
来自专栏酷玩时刻

微信公众号开发之模板消息

其实这个问题很简单,在【微信公众平台】现在已经可以直接查看自己的公众号都能使用那些接口。

37930
来自专栏北京马哥教育

Python在自动化运维时经常会用到的方法

本文由马哥教育Python自动化实战班6期学员推荐,转载自互联网,作者为seed,内容略经小编改编和加工,观点跟作者无关,最后感谢作者的辛苦贡献与付出。 随着信...

38080
来自专栏Web行业观察

事件驱动引擎会取代多线程编程吗

事件驱动编程是一种编程范式,这里程序的执行流由外部事件来决定。它的特点是包含一个事件循环,当外部事件发生时使用回调机制来触发相应的处理。另外两种常见的编程范式是...

24940
来自专栏嵌入式程序猿

进入main之前,都干了什么,老实招来

经常有程序猿会说软件上电后从main函数开始执行,其实是不对的,在进入main之前,经历了好多,今天就带你来熟识下IAR环境下,应用软件系统的main函数之前的...

318100
来自专栏同步博客

Redis应用----消息传递

  消息传递这一应用广泛存在于各个网站中,这个功能也是一个网站必不可少的。常见的消息传递应用有,新浪微博中的@我呀、给你评论然后的提示呀、赞赞赞提示、私信呀、甚...

18920
来自专栏跟着阿笨一起玩NET

从XML文件乱码问题,探寻其背后的原理

加入xml文件以<?xml version="1.0" encoding="utf-8" ?> 格式的;如果对xml文件进行修改了,其中包含中文字符的内容,另存...

18120

Cloudify中的部署组合

[这篇文章是由DeWayne Filppi撰写的。]

37760
来自专栏枕边书

解决问题,别扩展问题

最近有个需求需要统计一个方法的耗时,这个方法前后各打出一条日志,类似于 [INFO] 20180913 19:24:01.442 method start/en...

8610
来自专栏Python中文社区

Python爬虫:模拟登录知乎完全详解

專 欄 ❈ sunhaiyu,Python中文社区专栏作者 专栏地址: http://www.jianshu.com/u/4943cb2c6ea4 ❈ 这几天...

84090

扫码关注云+社区

领取腾讯云代金券