redis教程(三)-----redis缓存雪崩、缓存穿透、缓存预热

缓存雪崩

概念

缓存雪崩是由于原有缓存失效(过期),新缓存未到期间。所有请求都去查询数据库,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整个系统崩溃。

解决方案

加锁排队

一般并发量不是特别多的时候,使用最多的解决方案是加锁排队。

public object GetProductListNew()
        {
            const int cacheTime = 30;
            const string cacheKey = "product_list";
            const string lockKey = cacheKey;

            var cacheValue = CacheHelper.Get(cacheKey);
            if (cacheValue != null)
            {
                return cacheValue;
            }
            else
            {
                lock (lockKey)
                {
                    cacheValue = CacheHelper.Get(cacheKey);
                    if (cacheValue != null)
                    {
                        return cacheValue;
                    }
                    else
                    {
                        cacheValue = GetProductListFromDB(); //这里一般是 sql查询数据。
                        CacheHelper.Add(cacheKey, cacheValue, cacheTime);
                    }
                }
                return cacheValue;
            }
        }

缓存标记

加锁排队只是为了减轻数据库的压力,并没有提高系统吞吐量。假设在高并发下,缓存重建期间key是锁着的,这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时,这是个治标不治本的方法。还有一个解决办法解决方案是:给每一个缓存数据增加相应的缓存标记,记录缓存的是否失效,如果缓存标记失效,则更新数据缓存。

public object GetProductListNew()
        {
            const int cacheTime = 30;
            const string cacheKey = "product_list";
            //缓存标记。
            const string cacheSign = cacheKey + "_sign";

            var sign = CacheHelper.Get(cacheSign);
            //获取缓存值
            var cacheValue = CacheHelper.Get(cacheKey);
            if (sign != null)
            {
                return cacheValue; //未过期,直接返回。
            }
            else
            {
                CacheHelper.Add(cacheSign, "1", cacheTime);
                ThreadPool.QueueUserWorkItem((arg) =>
                {
                    cacheValue = GetProductListFromDB(); //这里一般是 sql查询数据。
                    CacheHelper.Add(cacheKey, cacheValue, cacheTime*2); //日期设缓存时间的2倍,用于脏读。
                });

                return cacheValue;
            }
        }

缓存标记:记录缓存数据是否过期,如果过期会触发通知另外的线程在后台去更新实际key的缓存。

缓存数据:它的过期时间比缓存标记的时间延长1倍,例:标记缓存时间30分钟,数据缓存设置为60分钟。 这样,当缓存标记key过期后,实际缓存还能把旧数据返回给调用端,直到另外的线程在后台更新完成后,才会返回新缓存。

这样做后,就可以一定程度上提高系统吞吐量。

缓存穿透

缓存穿透是指用户查询数据,在数据库没有,自然在缓存中也不会有。这样就导致用户查询的时候,在缓存中找不到,每次都要去数据库再查询一遍,然后返回空。这样请求就绕过缓存直接查数据库,这也是经常提的缓存命中率问题。

解决的办法就是:如果查询数据库也为空,直接设置一个默认值存放到缓存,这样第二次到缓冲中获取就有值了,而不会继续访问数据库,这种办法最简单粗暴。

public object GetProductListNew()
        {
            const int cacheTime = 30;
            const string cacheKey = "product_list";

            var cacheValue = CacheHelper.Get(cacheKey);if (cacheValue != null)
            {
                return cacheValue;
            }
            else
            {
                cacheValue = GetProductListFromDB(); //数据库查询不到,为空。

                if (cacheValue == null)
                {
                    cacheValue = string.Empty; //如果发现为空,设置个默认值,也缓存起来。
                }
                CacheHelper.Add(cacheKey, cacheValue, cacheTime);

                return cacheValue;
            }
        }

把空结果,也给缓存起来,这样下次同样的请求就可以直接返回空了,即可以避免当查询的值为空时引起的缓存穿透。同时也可以单独设置个缓存区域存储空值,对要查询的key进行预先校验,然后再放行给后面的正常缓存处理逻辑。

缓存预热

缓存预热就是系统上线后,将相关的缓存数据直接加载到缓存系统。这样避免,用户请求的时候,再去加载相关的数据。

解决思路:

  1、直接写个缓存刷新页面,上线时手工操作下。

  2、数据量不大,可以在WEB系统启动的时候加载。

  3、定时刷新缓存。

缓存更新

缓存淘汰的策略有两种:

  1、定时去清理过期的缓存。

  2、当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。

  两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂,具体用哪种方案,大家可以根据自己的应用场景来权衡。1. 预估失效时间 2. 版本号(必须单调递增,时间戳是最好的选择)3. 提供手动清理缓存的接口。

原文地址:https://www.cnblogs.com/alimayun/p/11007007.html

时间: 2024-11-05 20:43:33

redis教程(三)-----redis缓存雪崩、缓存穿透、缓存预热的相关文章

缓存雪崩 Cache Avalanche 缓存穿透 Cache Penetration 缓存击穿 Hotspot Invalid

一.无处不在的缓存缓存在计算机系统是无处不在,在CPU层面有L1-L3的Cache,在Linux中有TLB加速虚拟地址和物理地址的转换,在应用层有Redis等内存数据库缓存.在浏览器有本地缓存.手机有本地文件缓存等等.可见,缓存在计算机系统中有非常重要的地位,主要作用就是提高响应速度.减少磁盘读取等,本文主要讨论在高并发系统中的缓存系统.一句话概括缓存系统在高并发系统中的地位的话,就是: 如果高并发系统是烤羊肉串,那么缓存系统就是那一撮孜然...... 二.高并发系统中的缓存 缓存系统的作用 缓

redis缓存雪崩、穿透、击穿概念及解决办法

缓存雪崩 对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000 个请求,但是缓存机器意外发生了全盘宕机.缓存挂了,此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了.此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了. 这就是缓存雪崩. 大约在 3 年前,国内比较知名的一个互联网公司,曾因为缓存事故,导致雪崩,后台系统全部崩溃,事故从当天下午持续到晚上凌晨 3~4

redis教程(二)-----redis事务、记录日志到redis、分布式锁

redis事务 Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证: 批量操作在发送 EXEC 命令前被放入队列缓存. 收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行. 在事务执行过程,其他客户端提交的命令请求不会插入到事务执行命令序列中. 一个事务从开始到执行会经历以下三个阶段: 开始事务. 命令入队. 执行事务. 示例: //根据multi开启事务redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6

Redis教程03——Redis 发布/订阅(Pub/Sub)

Pub/Sub 订阅,取消订阅和发布实现了发布/订阅消息范式(引自wikipedia),发送者(发布者)不是计划发送消息给特定的接收者(订阅者).而是发布的消息分到不同的频道,不需要知道什么样的订阅者订阅.订阅者对一个或多个频道感兴趣,只需接收感兴趣的消息,不需要知道什么样的发布者发布的.这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑. F为了订阅foo和bar,客户端发出一个订阅的频道名称: SUBSCRIBE foo bar 其他客户端发到这些频道的消息将会被推送到所有订

C# Redis系列(三)-Redis发布订阅及客户端编程

发布订阅模型 Redis中的发布订阅 客户端编程示例 0.3版本Hredis 发布订阅模型 在应用级其作用是为了减少依赖关系,通常也叫观察者模式.主要是把耦合点单独抽离出来作为第三方,隔离易变化的发送方和接收方. 发送方:只负责向第三方发送消息.(杂志社把读者杂志交给邮局) 接收方:被动接收消息.(1:向邮局订阅读者杂志,2:门口去接邮过来的杂志) 第三方作用是:存储订阅杂志的接收方,并在杂志过来时送给接收方. (邮局) C#示例,发送方把杂志放到邮局里面: if (QA.AddBug()) E

Redis系列三 Redis数据类型

一 .Redis的五大数据类型 1.String(字符串) string是redis最基本的数据类型,可以理解成与 Memached一模一样的数据类型,一个key对应一个value. string 类型是二进制安全的.意思是redis的String可以包含任何数据.比如jpg的图片或者序列化的对象. string类型是redis最基本的数据类型,一个redis中字符串value最多可以是512M. 2.Hash(哈希,类似java里的Map) Redis Hash是一个键值对集合. Redis

redis学习三 redis持久化

1,快照持久化 1简介 redis可以通过创建快照来获得某个时间点上的内存内容的数据副本,有了副本之后,就可以将副本发送到其他redis服务器上从而创建相同数据的从服务器,同时快照留在原地以便重启redis的时候实现数据恢复. 2配置 save 60 1000  快照生成策略  如果服务器距离上一次成功生成快照已经超过六十秒,并且期间执行了至少1000次写操作. stop-writes-on-bgsave-error yes 创建快照文件失败后是否继续执行写命令 rdbcompression y

阿里面试Redis最常见的三个问题:缓存击穿、雪崩、穿透(带答案)

点赞再看,养成习惯,微信搜索[三太子敖丙]我所有文章都在这里,本文 GitHub https://github.com/JavaFamily 已收录,有一线大厂面试完整考点,文末有福利. 正文 上一期吊打系列我们提到了Redis的基础知识,还没看的小伙伴可以回顾一下 <吊打面试官>系列-Redis基础 那提到Redis我相信各位在面试,或者实际开发过程中对缓存雪崩,穿透,击穿也不陌生吧,就算没遇到过但是你肯定听过,那三者到底有什么区别,我们又应该怎么去防止这样的情况发生呢,我们有请下一位受害者

redis缓存穿透,缓存击穿,缓存雪崩原因+解决方案

###一.前言在我们日常的开发中,无不都是使用数据库来进行数据的存储,由于一般的系统任务中通常不会存在高并发的情况,所以这样看起来并没有什么问题,可是一旦涉及大数据量的需求,比如一些商品抢购的情景,或者是主页访问量瞬间较大的时候,单一使用数据库来保存数据的系统会因为面向磁盘,磁盘读/写速度比较慢的问题而存在严重的性能弊端,一瞬间成千上万的请求到来,需要系统在极短的时间内完成成千上万次的读/写操作,这个时候往往不是数据库能够承受的,极其容易造成数据库系统瘫痪,最终导致服务宕机的严重生产问题. 为了