详解缓存穿透/击穿/雪崩原理及其解决方案

目录
  • 1. 简介
  • 2. 缓存穿透
    • 2.1描述
    • 2.2 解决方案
  • 3. 缓存击穿
    • 3.1 描述
    • 3.2 解决方案
  • 4. 缓存雪崩
    • 4.1 描述
    • 4.1 解决方案
  • 5. 布隆过滤器
    • 5.1 描述
    • 5.2 数据结构
    • 5.3 “一定不在集合中”
    • 5.4 “可能在集合中”
    • 5.5 ”删除困难“
    • 5.6 为什么不使用HashMap呢?

1. 简介

如图所示,一个正常的请求

1.客户端请求张铁牛的博客。

2.服务首先会请求redis,查看请求的内容是否存在。

3.redis将请求结果返回给服务,如果返回的结果有数据则执行7;如果没有数据则会继续往下执行。

4.服务从数据库中查询请求的数据。

5.数据库将查询的结果返回给服务。

6.如果数据库有返回数据,则将返回的结果添加到redis。

7.将请求到的数据返回给客户端。

2. 缓存穿透

2.1描述

通过接口访问一个缓存和数据库都不存在的数据。

因为服务出于容错考虑,当请求从持久层查不到数据则不写入缓存,这将导致请求这个不存在的数据每次都要到持久层去查询,失去了缓存的意义。

此时,缓存起不到保护后端持久层的意义,就像被穿透了一样。导致数据库存在被打挂的风险。

2.2 解决方案

1.接口请求参数的校验。对请求的接口进行鉴权,数据合法性的校验等;比如查询的userId不能是负值或者包含非法字符等。

2.当数据库返回空值时,将空值缓存到redis,并设置合理的过期时间。

3.布隆过滤器。使用布隆过滤器存储所有可能访问的 key,不存在的 key 直接被过滤,存在的 key 则再进一步查询缓存和数据库。

3. 缓存击穿

3.1 描述

某个热点 key,在缓存过期的一瞬间,同时有大量的请求打进来,由于此时缓存过期了,所以请求最终都会走到数据库,造成瞬时数据库请求量大、压力骤增,导致数据库存在被打挂的风险。

3.2 解决方案

1.加互斥锁。当热点key过期后,大量的请求涌入时,只有第一个请求能获取锁并阻塞,此时该请求查询数据库,并将查询结果写入redis后释放锁。后续的请求直接走缓存。

2.设置缓存不过期或者后台有线程一直给热点数据续期。

4. 缓存雪崩

4.1 描述

大量的热点数据过期时间相同,导致数据在同一时刻集体失效。造成瞬时数据库请求量大、压力骤增,引起雪崩,导致数据库存在被打挂的风险。

4.1 解决方案

1.将热点数据的过期时间打散。给热点数据设置过期时间时加个随机值。

2.加互斥锁。当热点key过期后,大量的请求涌入时,只有第一个请求能获取锁并阻塞,此时该请求查询数据库,并将查询结果写入redis后释放锁。后续的请求直接走缓存。

3.设置缓存不过期或者后台有线程一直给热点数据续期。

5. 布隆过滤器

5.1 描述

布隆过滤器是防止缓存穿透的方案之一。布隆过滤器主要是解决大规模数据下不需要精确过滤的业务场景,如检查垃圾邮件地址,爬虫URL地址去重, 解决缓存穿透问题等。

布隆过滤器:在一个存在一定数量的集合中过滤一个对应的元素,判断该元素是否一定不在集合中或者可能在集合中。它的优点是空间效率和查询时间都比一般的算法要好的多,缺点是有一定的误识别率和删除困难。

5.2 数据结构

布隆过滤器是基于bitmap和若干个hash算法实现的。如下图所示:

1.元素tie经过hash1,hash2,hash3运算出对应的三个值落到了数组下标为4,6,8的位置上,并将其位置的默认值0,修改成1

2.元素niu同理落到了数组下标为1,3,4的位置上,并将其位置的默认值0,修改成1

此时bitmap中已经存储了tieniu数据元素。

当请求想通过布隆过滤器判断tie元素在程序中是否存在时,通过hash运算结果到数组对应下标位置上发现值已经都被置为1,此时返回true

5.3 “一定不在集合中”

如图所示:

​ 元素zhang通过布隆过滤器判断时,下标0,2都为0,则直接返回false

也就是当判断不在bitmap中的元素时,经过hash运算得到的结果在bitmap中只要有一个为0,则该数据一定不存在。

5.4 “可能在集合中”

如图所示:

​ 元素shuaibi通过布隆过滤器判断时,hash运算的结果落到了下标1,3,8上,此时对应下标位置的值都为1,则直接返回true

这下就尴尬了,因为实际程序中并没有数据shuaibi,但布隆过滤器返回的结果显示有这个元素。这就是布隆过滤器的缺点,存在误判情况。

5.5 ”删除困难“

为什么布隆过滤器删除困难呢,如图所示:

如果删除了“tie”元素,4号位被置为0,则会影响niu元素的判断,因为4号位为0,进行数据校验时返回0,则会认为程序中没有niu元素。

那小伙伴会问,4号位不置为0,行不行?

如果删除了元素,hash碰撞的数组下标不置为0,那么如果继续验证该元素的话,布隆过滤器会继续返回true,但实际上元素已经删除了。

所以布隆过滤器数据删除困难,如果要删除的话,可以参考Counting Bloom Filter

5.6 为什么不使用HashMap呢?

如果用HashSet或Hashmap存储的话,每一个用户ID都要存成int,占4个字节即32bit。而一个用户在bitmap中只需要1个bit,内存节省了32倍。

并且大数据量会产生大量的hash冲突,结果就是产生hash冲突的数据,仍然会进行遍历挨个比对(即使转成红黑树),这样对内存空间和查询效率的提升,仍然是有限的。

当然:数据量不大时,尽管使用。而且hashmap方便进行CRUD😂

到此这篇关于详解缓存穿透/击穿/雪崩原理及其解决方案的文章就介绍到这了,更多相关缓存穿透/击穿/雪崩内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 详解缓存穿透击穿雪崩解决方案

    一:前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 二:缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义.在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞. 三:解决方案 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足

  • 详解缓存穿透/击穿/雪崩原理及其解决方案

    目录 1. 简介 2. 缓存穿透 2.1描述 2.2 解决方案 3. 缓存击穿 3.1 描述 3.2 解决方案 4. 缓存雪崩 4.1 描述 4.1 解决方案 5. 布隆过滤器 5.1 描述 5.2 数据结构 5.3 "一定不在集合中" 5.4 "可能在集合中" 5.5 "删除困难" 5.6 为什么不使用HashMap呢? 1. 简介 如图所示,一个正常的请求 1.客户端请求张铁牛的博客. 2.服务首先会请求redis,查看请求的内容是否存在.

  • 详解Redis缓存穿透/击穿/雪崩原理及其解决方案

    目录 1.简介 2.缓存穿透 2.1描述 2.2解决方案 3.缓存击穿 3.1描述 3.2解决方案 4.缓存雪崩 4.1描述 4.1解决方案 5.布隆过滤器 5.1描述 5.2数据结构 5.3"一定不在集合中" 5.4"可能在集合中" 5.5"删除困难" 5.6为什么不使用HashMap呢? 1. 简介 如图所示,一个正常的请求 1.客户端请求张铁牛的博客. 2.服务首先会请求redis,查看请求的内容是否存在. 3.redis将请求结果返回给服

  • Redis中缓存穿透/击穿/雪崩问题和解决方法

    目录 缓存问题 1. 缓存穿透---查不到 解决方案 2. 缓存击穿---量太大,缓存过期 解决方案 3. 缓存雪崩 解决方案 缓存问题 1. 缓存穿透---查不到 缓存穿透是指用户想查询一个数据,发现Redis中没有,也就是缓存没有命中,就向持久性数据库发起查询,发现数据库也没有这个数据,于是查询失败了. 当用户请求很多的情况下,缓存没有命中,数据库也没有数据,会给数据库造成很大的压力,这就是缓存穿透. 解决方案 第一种解决方案:使用布隆过滤器 使用布隆过滤器之后,将存储的数据放入布隆过滤器中

  • 详解http访问解析流程原理

    详解http访问解析流程原理 http访问网址域名解析流程: 1.在浏览器中输入www.qq.com域名,操作系统会先检查自己本地的hosts文件是否有这个网址映射关系,如果有,就先调用这个IP地址映射,完成域名解析. 2.如果hosts里没有这个域名的映射,则查找本地DNS解析器缓存,是否有这个网址映射关系,如果有,直接返回,完成域名解析. 3.如果hosts与本地DNS解析器缓存都没有相应的网址映射关系,首先会找TCP/ip参数中设置的首选DNS服务器,在此我们叫它本地DNS服务器,此服务器

  • 详解vue 组件的实现原理

    组件机制的设计,可以让开发者把一个复杂的应用分割成一个个功能独立组件,降低开发的难度的同时,也提供了极好的复用性和可维护性.本文我们一起从源码的角度,了解一下组件的底层实现原理. 组件注册时做了什么? 在Vue中使用组件,要做的第一步就是注册.Vue提供了全局注册和局部注册两种方式. 全局注册方式如下: Vue.component('my-component-name', { /* ... */ }) 局部注册方式如下: var ComponentA = { /* ... */ } new Vu

  • 详解IOS WebRTC的实现原理

    概述 它在2011年5月开放了工程的源代码,在行业内得到了广泛的支持和应用,成为下一代视频通话的标准. WebRTC的音视频通信是基于P2P,那么什么是P2P呢? 它是点对点连接的英文缩写. P2P连接模式 一般我们传统的连接方式,都是以服务器为中介的模式: 类似http协议:客户端?服务端(当然这里服务端返回的箭头仅仅代表返回请求数据). 我们在进行即时通讯时,进行文字.图片.录音等传输的时候:客户端A?服务器?客户端B. 而点对点的连接恰恰数据通道一旦形成,中间是不经过服务端的,数据直接从一

  • 详解C# ConcurrentBag的实现原理

    一.ConcurrentBag类 ConcurrentBag<T>对外提供的方法没有List<T>那么多,但是同样有Enumerable实现的扩展方法.类本身提供的方法如下所示. 名称 说明 Add 将对象添加到 ConcurrentBag 中. CopyTo 从指定数组索引开始,将 ConcurrentBag 元素复制到现有的一维 Array 中. Equals(Object) 确定指定的 Object 是否等于当前的 Object. (继承自 Object.) Finalize

  • Android 图文详解Binder进程通信底层原理

    之前了解到进程与多进程,涉及多进程不可避免的遇到了进程间通信,说到进程间通信,Binder 成了一道绕不过的坎.接下来咱们逐一了解.

  • 详解Redis分布式锁的原理与实现

    目录 前言 使用场景 为什么要使用分布式锁 如何使用分布式锁 流程图 分布式锁的状态 分布式锁的特点 分布式锁的实现方式(以redis分布式锁实现为例) 总结 前言 在单体应用中,如果我们对共享数据不进行加锁操作,会出现数据一致性问题,我们的解决办法通常是加锁.在分布式架构中,我们同样会遇到数据共享操作问题,此时,我们就需要分布式锁来解决问题,下面我们一起聊聊使用redis来实现分布式锁. 使用场景 库存超卖 比如 5个笔记本 A 看 准备买3个 B 买2个 C 4个 一下单 3+2+4 =9

随机推荐