redis 缓存穿透、缓存雪崩和缓存击穿

Redis： 理解为防弹衣

mysql ：理解为身体

过程： 先从Redis查询数据， 存在返回， 不存在再查询数据库

	原因	解决方案
缓存雪崩	缓存集中失效，造成数据库压力过大	不同分类的Key设置不同的过期时间，避免集中失效 热点Key 缓存时间长一些 冷门Key 缓存时间短一些
缓存击穿	查询一个数据库，缓存都不存在的数据，导致每次请求都查询数据库	缓存空对象
缓存穿透	热点key过期，持续的大并发就穿破缓存，直接请求数据库	热点Key不过期 监控请求频率，达到一定频次，设置为热点Key不过期

 

 

类型	结果	应用场景
字符串 String	键值对 (Key - Value)	缓存不常改变的数据；网站访问量，在线人数 SET user_name "John Doe"
哈希 Hash	数据对象	缓存用户信息： 性别，年龄，地址等 HSET user:1 name "John" age 25 address "New York"
列表 List	按照顺序排列的字符串 在头部/尾部 添加删除数据做	任务队列 LPHSH k1 a b c   向k1 左边添加元素      结果： a b c RPHSH k1 x y   向k1 右边添加元素           结果： a b c x y
集合 Set	无序且唯一的字符窜集合
有序集合 ZSet	有序集合	排行榜，点击量     文章热读，积分排行

 

 

 

参考： https://baijiahao.baidu.com/s?id=1619572269435584821&wfr=spider&for=pc

 

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。本篇文章，并不是要更加完美的解决这三个问题，也不是要颠覆业界流行的解决方案。而是，从实际代码操作，来演示这三个问题现象。之所以要这么做，是因为，仅仅看这些问题的学术解释，脑袋里很难有一个很形象的概念，有了实际的代码演示，可以加深对这些问题的理解和认识。

缓存穿透

缓存穿透，是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。

Redis缓存流程

代码流程

参数传入对象主键ID根据key从缓存中获取对象如果对象不为空，直接返回如果对象为空，进行数据库查询如果从数据库查询出的对象不为空，则放入缓存（设定过期时间）想象一下这个情况，如果传入的参数为-1，会是怎么样？这个-1，就是一定不存在的对象。就会每次都去查询数据库，而每次查询都是空，每次又都不会进行缓存。假如有恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮数据库。即便是采用UUID，也是很容易找到一个不存在的KEY，进行攻击。

小编在工作中，会采用缓存空值的方式，也就是【代码流程】中第5步，如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。

缓存空值

缓存雪崩

缓存雪崩，是指在某一个时间段，缓存集中过期失效。

产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

小编在做电商项目的时候，一般是采取不同分类商品，缓存不同周期。在同一分类中的商品，加上一个随机因子。这样能尽可能分散缓存过期时间，而且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。

缓存时间加入suijiyinzi

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

小编在做电商项目的时候，把这货就成为“爆款”。

其实，大多数情况下这种爆款很难对数据库服务器造成压垮性的压力。达到这个级别的公司没有几家的。所以，务实主义的小编，对主打商品都是早早的做好了准备，让缓存永不过期。即便某些商品自己发酵成了爆款，也是直接设为永不过期就好了。

大道至简，mutex key互斥锁真心用不上。

结束语

在流行的问题面前一定有流行的解决方案，但有时候，也要根据自己的实际情况酌情处理。大胆设计，说不定你的解决方案就会被流行呢？