生命无罪,健康万岁,我是laity。
我曾七次鄙视自己的灵魂:
第一次,当它本可进取时,却故作谦卑;
第二次,当它在空虚时,用爱欲来填充;
第三次,在困难和容易之间,它选择了容易;
第四次,它犯了错,却借由别人也会犯错来宽慰自己;
第五次,它*软弱,却把它认为是生命的坚韧;
第六次,当它鄙夷一张丑恶的嘴脸时,却不知那正是自己面具中的一副;
第七次,它侧身于生活的污泥中,虽不甘心,却又畏首畏尾。
前言
关于缓存异常,我们常见的有三个问题:缓存雪崩、缓存击穿、缓存穿透。 这三个问题一旦发生,会导致大量请求直接落到数据库层面。如果请求的并发量很大,会影响数据库的运行,严重的会导致数据库宕机。
为了避免异常带来的损失,我们需要了解每种异常的原因以及解决方案,提高系统的可靠性。
高并发下缓存雪崩
Redis中的数据大面积失效(时间过期)的情景
- 缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到 DB,DB 瞬时压力过重雪崩。
- 解决方案:
-
均匀过期:
给热点数据设置不同的过期时间,给每个key的失效时间加一个随机值;- 原有的失效时间基础上增加一个随机值,比如 1-5 分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
-
设置热点数据永不过期:
不设置失效时间,有更新的话,需要更新缓存; -
服务降级:
指服务针对不同的数据采用不同的处理方式:- 业务访问的是非核心数据,直接返回预定义信息、空值或者报错;
- 业务访问核心数据,则允许访问缓存,如果缓存缺失,可以读取数据库。
-
Redis 缓存实例发生故障宕机的场景
- 实现服务熔断或者请求限流机制
- 通过监测Redis以及数据库实例所在服务器负载指标,如果发现Redis服务宕机,导致数据库的负载压力增大,我们可以启动服务熔断机制,暂停对缓存服务的访问。
- 但是这种方法对业务应用的影响比较大,我们也可以通过限流的方式降低这种影响。
举个例子:比如业务系统正常运行时,请求入口每秒最大允许进入的请求数是1万个,其中9000请求个可以被缓存处理,余下1000个会发送给数据库处理。一旦发生雪崩,数据库每秒处理的请求突然增加到1万个,此时我们就可以启动限流机制。在前端请求入口处,只允许每秒进入1000个请求,其他的直接拒绝掉。这样就可以避免大量并发请求发送给数据库。
- 事前预防
- 通过主从节点的方式构建 Redis 缓存高可靠集群。 如果 Redis 缓存的主节点故障宕机了,从节点还可以切换成为主节点,继续提供缓存服务,避免了由于缓存实例宕机而导致的缓存雪崩问题。
高并发下缓存穿透
就是去查询一个一定不存在的数据
- 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中,将去查询数据库,但是数据库也无此记录,我们没有将这次查询的 null 写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。
- 在流量大时,可能 DB 就挂掉了,要是有人利用不存在的 key 频繁攻击我们的应用,这就是漏洞。
- 解决方案:
- 缓存空结果、并且设置短的过期时间。(null结果进行缓存)
- 如果有大量的Key穿透,缓存空对象会占用宝贵的内存空间。针对这种情况可以给空对象设置过期时间。
- 设置过期时间之后,可能会有缓存与数据库不一致的情况(
后期可能又有这个条数据了
)。
- 布隆过滤:快速判断数据是否存在,避免从数据库中查询数据是否存在,减轻数据库压力。
- 接口层增加校验:用户鉴权、参数校验(请求参数是否合法、请求字段是否不存在等等。
- 缓存空结果、并且设置短的过期时间。(null结果进行缓存)
高并发下缓存击穿
一个key过期,但是被高访问
- 对于一些设置了过期时间的 key,如果这些 key 可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。
- 这个时候,需要考虑一个问题:如果这个 key 在大量请求同时进来前正好失效,那么所有对这个 key 的数据查询都落到 db,我们称为缓存击穿。
- 解决方案:
- 设置热点数据永不过期:不设置失效时间,有更新的话,需要更新缓存;
- 加互斥锁:单机可以使用synchronized、lock,分布式可以使用lua脚本或分布式锁Redisson。
zookeeper与etcd,用来做锁都比redis要好很多
关于缓存异常有兴趣的同学可以看下这篇:关于缓存异常:缓存雪崩、击穿、穿透的解决方案
关于分布式锁有兴趣的同学可以看下这篇:Redis分布式锁的正确打开方式
布隆过滤器
布隆过滤器(Bloom Filter)是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。
- 优点:空间效率和查询时间都远远超过一般的算法。
- 缺点:有一定的误识别率,删除困难。
布隆过滤器原理
布隆过滤器本质上是一个初始值都为 0 的 二进制数组和 N 个哈希函数组成。
当我们想标记某个数据存在时(例如,数据x已被写入数据库),布隆过滤器会通过三个操作完成标记:
- 首先,使用 N 个哈希函数,分别计算这个数据的哈希值,得到 N 个哈希值。
- 然后,我们把这 N 个哈希值对 bit 数组的长度取模,得到每个哈希值在数组中的对应位置。
- 最后,我们把对应位置的 bit 位设置为 1,这就完成了在布隆过滤器中标记数据的操作。
如下图所示:
三次哈希,对应的二进制数组下标分别是 1、3、7,将原始数据从 0 变为 1。
同样的,我们标记数据y的逻辑也是一样的。如下图:
三次哈希,对应的二进制数组下标分别是 1、5、9,将原始数据从 0 变为 1。
下标 1,之前已经被操作设置成 1,则本次认为是哈希冲突,不需要改动。
Hash 规则:如果在 Hash 后,原始位它是 0 的话,将其从 0 变为 1;如果本身这一位就是 1 的话,则保持不变。
正是因为存在哈希冲突,导致布隆过滤器的判断存在误差。
也因为哈希冲突的存在,导致布隆过滤器不能轻易删除数据,存在误删的风险。
布隆过滤器减少误差的方法:
- 增加二进制位数组的长度,这样hash后的数据会更加离散化,出现冲突的概率会大大降低;
- 增加Hash的次数,变相的增加数据特征,特征越多,冲突的概率越小。
布隆过滤器如何使用
比如,当查询一件商品的缓存信息时,我们首先要判断这件商品是否存在。
- 通过三个哈希函数对商品id计算哈希值;
- 然后,在布隆数组中查找访问对应的位值,0或1;
- 判断,三个值中,只要有一个不是1,那么我们认为数据是不存在的。
如下图:
注意:布隆过滤器只能精确判断数据不存在情况,对于存在我们只能说是可能,因为存在Hash冲突情况,当然这个概率非常低。
在Java中使用布隆过滤器
至于在Java应用中使用布隆过滤器,我们可以通过Redisson
实现,它内置了布隆过滤器。
首先引入依赖
<!-- Redis锁 - 红锁:分布式锁,分布式对象等功能的框架 -->
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.17.7</version>
</dependency>
代码示例:
package com.laity.product;
import org.junit.jupiter.api.Test;
import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
/**
* @author: Laity
* @Project: JavaLaity
* @Package: com.laity.product.config.MyRedissonConfig
* @Date: 2022年10月18日 01:39
* @Description: 测试基于redisson使用布隆过滤
*/
@SpringBootTest
public class RedissonBloomFilter {
@Autowired
private RedissonClient redissonClient;
@Test
void redissonBloom(){
RBloomFilter<String> bloomFilter = redissonClient.getBloomFilter("test-bloom-filter");
// 初始化布隆过滤器,数组长度100W,误判率 1%
bloomFilter.tryInit(1000000L, 0.01);
// 添加数据
bloomFilter.add("Shawn");
// 判断是否存在
System.out.println(bloomFilter.contains("laity"));
System.out.println(bloomFilter.contains("itlaity"));
}
}
运行结果:
false // 肯定不存在
true // 可能存在,有1%的误判率
与其让平凡与胆怯缚住自己的手脚,不如倾生命的全部能量奋力一搏。我是Laity,正在前行的Laity。