1. 击穿

缓存击穿:Redis中一个热点key在失效(过期或者被清理掉了)的同时,大量的请求过来,从而会全部到达数据库,压垮数据库。

alt

1.1 解决办法

1.1.1 设置热点数据永不过期

对于某个需要频繁获取的信息,缓存在Redis中,并设置其永不过期。当然这种方式比较粗暴,对于某些业务场景是不适合的。

1.1.2 定时更新

比如这个热点数据的过期时间是1h,那么每到59minutes时,通过定时任务去更新这个热点key,并重新设置其过期时间。

1.1.3 分布式锁

alt

这是解决缓存穿透比较常用的方法。

简单来说就是在Redis中根据key获得的value值为空时,先锁上,然后从数据库加载,加载完毕,释放锁。若其他线程也在请求该key时,发现获取锁失败,则睡眠一段时间(比如100ms)后重试。

redis是单进程实例,高并发后排队访问reids取值(get key),如果没有取到值,则向redis发送 setnx 命令(setnx命令key不存在时则新增成功,这时类似于一个锁),新增成功的访问数据库。失败的睡眠一小会,然后重新查询。

1.2 问题

1.2.1 问题1 死锁

  • 如果访问数据库的线程挂了,其他线程也无法访问数据库了,相当于造成了死锁

  • 可以设置 setnx 的key的过期时间

1.2.1.1 问题1衍生问题

  • 如果访问数据库的线程没挂,但是key超时了

  • 多线程:一个线程取DB,一个线程监控是否取回来,如果没有取回来则更新一下锁的时间

2. 穿透

缓存穿透:缓存和数据库中都没有的数据,可用户还是源源不断的发起请求,导致每次请求都会到数据库,从而压垮数据库。

alt

2.1 解决办法

2.1.1 业务层校验

用户发过来的请求,根据请求参数进行校验,对于明显错误的参数,直接拦截返回。

比如,请求参数为主键自增id,那么对于请求小于0的id参数,明显不符合,可以直接返回错误请求。

2.1.2 不存在数据设置短过期时间

对于某个查询为空的数据,可以将这个空结果进行Redis缓存,但是设置很短的过期时间,比如30s,可以根据实际业务设定。注意一定不要影响正常业务。

2.1.3 布隆过滤器

布隆过滤器是一种数据结构,利用极小的内存,可以判断大量的数据“一定不存在或者可能存在”。

对于缓存击穿,我们可以将查询的数据条件都哈希到一个足够大的布隆过滤器中,用户发送的请求会先被布隆过滤器拦截,一定不存在的数据就直接拦截返回了,从而避免下一步对数据库的压力。

2.2 redis集成Bloom模块

alt

  • 进去后查看readme有详细的使用方法

文档和完整的命令参考 https://redis.io/

alt

  • 克隆RedisBloom
git clone --recursive https://github.com/RedisBloom/RedisBloom.git

cd RedisBloom/

alt

  • 按照readme执行命令
./sbin/setup

bash -l

make

alt

alt

  • 将redisbloom.so放到redis5目录下
cp /usr/local/Redis/bf/RedisBloom/bin/linux-x64-release/redisbloom.so /usr/local/Redis/redis5/

cd /usr/local/Redis/redis5/

alt

  • 不修改配置文件使用redisBloom扩展库命令
redis-server --loadmodule /usr/local/Redis/redis5/redisbloom.so

alt

挂载redisBloom扩展库后,对应的redis客户端就可以通过bf + Tab键使用扩展库命令

redis-cli -p 6379

alt

3. 雪崩

缓存雪崩:Redis中缓存的数据大面积同时失效,或者Redis宕机,从而会导致大量请求直接到数据库,压垮数据库。

alt

3.1 解决办法

3.1.1 与时点性无关 <-> 设置有效期均匀分布

避免缓存设置相近的有效期,我们可以在设置有效期时增加随机值;

或者统一规划有效期,使得过期时间均匀分布。

3.1.2 零点大量的key失效

业务层判断到零点随机延时一会,错开大量的key同时访问。加强依赖击穿方案

3.1.3 数据预热

对于即将来临的大量请求,我们可以提前走一遍系统,将数据提前缓存在Redis中,并设置不同的过期时间。

3.1.4 保证Redis服务高可用

Redis的哨兵模式和集群模式,为防止Redis集群单节点故障,可以通过这两种模式实现高可用。