CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章详解Redis缓存穿透/击穿/雪崩原理及其解决方案由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

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中已经存储了tie，niu数据元素.

当请求想通过布隆过滤器判断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 。

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

原文链接：https://www.cnblogs.com/ludangxin/p/15129434.html 。

最后此篇关于详解Redis缓存穿透/击穿/雪崩原理及其解决方案的文章就讲到这里了,如果你想了解更多关于详解Redis缓存穿透/击穿/雪崩原理及其解决方案的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。