目前的IO设备远不能满足互联网应用海量的读写请求。于是便出现了缓存,利用内存的高速读写性能来应付海量的查询请求。然而内存资源非常宝贵,将全量数据存储在内存中显然是不切合实际的。因此目前采用内存和IO结合的方式,内存只存储热点数据,而IO设备存储全量数据。 缓存的设计包含很多技巧,设计不当将会导致严重的后果。本文将介绍缓存使用中常见的三大问题,并给出相应的解决方案。
1. 缓存穿透
在大多数互联网应用中,缓存的使用方式如下图所示:
- 当业务系统发起某一个查询请求时,首先判断缓存中是否有该数据;
- 如果缓存中存在,则直接返回数据;
- 如果缓存中不存在,则再查询数据库,然后返回数据。
了解了上述过程后,下面说说缓存穿透。
1.1 什么是缓存穿透?
业务系统要查询的数据根本就存在!当业务系统发起查询时,按照上述流程,首先会前往缓存中查询,由于缓存中不存在,然后再前往数据库中查询。由于该数据压根就不存在,因此数据库也返回空。这就是缓存穿透。
综上所述:业务系统访问压根就不存在的数据,就称为缓存穿透。
1.2 缓存穿透的危害
如果存在海量请求查询压根就不存在的数据,那么这些海量请求都会落到数据库中,数据库压力剧增,可能会导致系统崩溃(你要知道,目前业务系统中最脆弱的就是IO,稍微来点压力它就会崩溃,所以我们要想种种办法保护它)。
1.3 为什么会发生缓存穿透?
发生缓存穿透的原因有很多,一般为如下两种:
- 恶意攻击,故意营造大量不存在的数据请求我们的服务,由于缓存中并不存在这些数据,因此海量请求均落在数据库中,从而可能会导致数据库崩溃。
- 代码逻辑错误。这是程序员的锅,没啥好讲的,开发中一定要避免!
1.4 缓存穿透的解决方案
下面来介绍两种防止缓存穿透的手段。
1.4.1 缓存空数据
之所以发生缓存穿透,是因为缓存中没有存储这些空数据的key,导致这些请求全都打到数据库上。
那么,我们可以稍微修改一下业务系统的代码,将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时,缓存直接返回null,而无需查询数据库。
1.4.2 BloomFilter
第二种避免缓存穿透的方式即为使用BloomFilter。
它需要在缓存之前再加一道屏障,里面存储目前数据库中存在的所有key,如下图所示:
当业务系统有查询请求的时候,首先去BloomFilter中查询该key是否存在。若不存在,则说明数据库中也不存在该数据,因此缓存都不要查了,直接返回null。若存在,则继续执行后续的流程,先前往缓存中查询,缓存中没有的话再前往数据库中的查询。
1.4.3 两种方案的比较
这两种方案都能解决缓存穿透的问题,但使用场景却各不相同。
对于一些恶意攻击,查询的key往往各不相同,而且数据贼多。此时,第一种方案就显得提襟见肘了。因为它需要存储所有空数据的key,而这些恶意攻击的key往往各不相同,而且同一个key往往只请求一次。因此即使缓存了这些空数据的key,由于不再使用第二次,因此也起不了保护数据库的作用。 因此,对于空数据的key各不相同、key重复请求概率低的场景而言,应该选择第二种方案。而对于空数据的key数量有限、key重复请求概率较高的场景而言,应该选择第一种方案。
2. 缓存雪崩
2.1 什么是缓存雪崩?
通过上文可知,缓存其实扮演了一个保护数据库的角色。它帮数据库抵挡大量的查询请求,从而避免脆弱的数据库受到伤害。
如果缓存因某种原因发生了宕机,那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力,它就会崩溃。
这就是缓存雪崩。
2.2 如何避免缓存雪崩?
2.2.1 使用缓存集群,保证缓存高可用
也就是在雪崩发生之前,做好预防手段,防止雪崩的发生。 PS:关于分布式高可用问题不是今天讨论的重点,套路就那些,后面会有高可用的相关文章,尽请关注。
2.2.2 使用Hystrix
Hystrix是一款开源的“防雪崩工具”,它通过 熔断、降级、限流三个手段来降低雪崩发生后的损失。
Hystrix就是一个Java类库,它采用命令模式,每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值,Hystrix将会拒绝随后该服务的所有请求,直接返回一个预设的结果。这就是所谓的**“熔断”。当经过一段时间后,Hystrix会放行该服务的一部分请求,再次统计它的请求失败率。如果此时请求失败率符合预设值,则完全打开限流开关;如果请求失败率仍然很高,那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而Hystrix向那些被拒绝的请求直接返回一个预设结果,被称为“降级”**。
更多Hystrix的介绍请参阅:https://segmentfault.com/a/1190000005988895
3. 热点数据集中失效
3.1 什么是热点数据集中失效?
我们一般都会给缓存设定一个失效时间,过了失效时间后,该数据库会被缓存直接删除,从而一定程度上保证数据的实时性。
但是,对于一些请求量极高的热点数据而言,一旦过了有效时间,此刻将会有大量请求落在数据库上,从而可能会导致数据库崩溃。其过程如下图所示:
如果某一个热点数据失效,那么当再次有该数据的查询请求[req-1]时就会前往数据库查询。但是,从请求发往数据库,到该数据更新到缓存中的这段时间中,由于缓存中仍然没有该数据,因此这段时间内到达的查询请求都会落到数据库上,这将会对数据库造成巨大的压力。此外,当这些请求查询完成后,都会重复更新缓存。
3.2 解决方案
3.2.1 互斥锁
我们可以使用缓存自带的锁机制,当第一个数据库查询请求发起后,就将缓存中该数据上锁;此时到达缓存的其他查询请求将无法查询该字段,从而被阻塞等待;当第一个请求完成数据库查询,并将数据更新值缓存后,释放锁;此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。
当某一个热点数据失效后,只有第一个数据库查询请求发往数据库,其余所有的查询请求均被阻塞,从而保护了数据库。但是,由于采用了互斥锁,其他请求将会阻塞等待,此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做。
互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题,而在实际业务中,往往会存在一批热点数据同时失效的场景。那么,对于这种场景该如何防止数据库过载呢?
3.3.2 设置不同的失效时间
当我们向缓存中存储这些数据的时候,可以将他们的缓存失效时间错开。这样能够避免同时失效。如:在一个基础时间上加/减一个随机数,从而将这些缓存的失效时间错开。