【Redis】之雪崩、穿透、击穿

最新推荐文章于 2025-03-29 02:20:31 发布

王廷云的博客

最新推荐文章于 2025-03-29 02:20:31 发布

阅读量426

点赞数

分类专栏： Redis 文章标签： redis

本文链接：https://blog.youkuaiyun.com/aiwangtingyun/article/details/123996226

版权

Redis 专栏收录该内容

14 篇文章

订阅专栏

1、缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生；
2、一般并发量不是特别多的时候，使用最多的解决方案是加锁排队；
3、给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。

二、缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案：

1、接口层增加校验，如用户鉴权校验，ID 做基础校验，ID<=0 的直接拦截；
2、从缓存取不到的数据，在数据库中也没有取到，这时也可以将 key-value 对写为 key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个 ID 暴力攻击；
3、采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 Bitmap 中，一个一定不存在的数据会被这个 Bitmap 拦截掉，从而避免了对底层存储系统的查询压力。

布隆过滤器（推荐使用）

布隆过滤器的原理就是引入了 k(k>1)*k(k>1) 个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程；
布隆过滤器的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难；
Bloom-Filter 算法的核心思想就是利用多个不同的 Has h函数来解决冲突；
Bloom-Filter 一般用于在大数据量的集合中判定某元素是否存在。

Hash 存在一个冲突（碰撞）的问题，用同一个 Hash 得到的两个地址值有可能相同。为了减少冲突，我们可以多引入几个 Hash，如果通过其中的一个 Hash 值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的 Hash 函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是 Bloom-Filter 的基本思想。

`Bitmap` 介绍

对于空间的利用到达了一种极致，那就是 Bitmap 和布隆过滤器（Bloom Filter）；
Bitmap 就是典型的哈希表；
Bitmap 的缺点是，Bitmap 对于每个元素只能记录 1bit 信息，如果还想完成额外的功能，恐怕只能靠牺牲更多的空间、时间来完成了。

三、缓存击穿

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

解决方案

1、设置热点数据永远不过期；
2、加互斥锁，互斥锁。

四、缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的（即使是有损服务）。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

缓存降级的最终目的是保证核心服务可用。而且有些服务是无法降级的（比如：加入购物车、结算等）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；可以参考日志级别设置预案：

一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止 Redis 服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis 出现问题，不去数据库查询，而是直接返回默认值给用户。

五、缓存热点 KEY

缓存中的一个Key(比如一个促销商品)，在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

对缓存查询加锁，如果 KEY 不存在，就加锁，然后查 DB 入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。

六、热点数据与冷数据

直接上结论： 热点数据，缓存才有价值！

相对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。所以，频繁修改的数据，看情况考虑使用缓存。

对于热点数据，比如我们的网站首页，网站导航信息等等，缓存以后可能读取数十万次。

数据更新前至少读取两次，缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。

那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们产品的点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到 Redis 缓存，减少数据库压力。