详解Java redis中缓存穿透 缓存击穿 雪崩三种现象以及解决方法

目录
  • 前言
  • 一、缓存穿透
  • 二、缓存击穿
  • 三、雪崩现象
  • 总结

前言

本文主要阐述redis中的三种现象

1.缓存穿透

2.缓存击穿

3.雪崩现象

本文主要说明本人对三种情况的理解,如果需要知道redis基础请查看其他博客,加油!

一、缓存穿透

理解:何为缓存穿透,先要了解穿透,这样有助于区分穿透和击穿,穿透就类似于伤害一点一点的累计,最终打到穿透的目的,类似于射手,一下一下普通攻击,最终杀死对方,先上图

先来描述一下缓存穿透的过程:

1.由于我们取数据的原则是先查询redis上,如果redis上有数据那么我们就取redis,如果没有则对数据库进行查询

2.当我们的应用服务器压力变大(例如我们双十一进行购物)

3.那么我们同时大量数据访问redis,而redis中只有其中几条数据的信息,那么我们就会对数据库进行大量的查询(redis命中率降低)

4.导致数据库崩溃

以上的过程就是缓存穿透

解决办法:

1.对空值进行缓存

2.设置黑(白)名单

3.采用布隆过滤器(布隆底层实际原理类似于优化版的使用bitmap进行缓存查询)

二、缓存击穿

理解:何为缓存击穿,击穿其实就是类似于爆发伤害,类似于高爆发的法师,一套技能瞬间杀死对方,上图

先来描述一下缓存击穿的过程:

1.由于我们取数据的原则是先查询redis上,如果redis上有数据那么我们就取redis,如果没有则对数据库进行查询,击穿的结果是redis还在正常运行,mysql崩了

2.当我们数据库(mysql)访问量瞬间增加(例如我们双十一进行抢制定的商品)

3.而此时,我们的redis上相对应的key突然过期,那么我们把查询压力全给mysql

4.导致数据库崩溃

以上的过程就是缓存击穿

解决办法:

1.预先设置热门数据(例如先缓存好制定商品的信息)

2.实施调整(人工延长key过期时间)

3.使用锁(影响效率)

三、雪崩现象

理解:何为雪崩,顾名思义,就是一片雪花导致整个系统的崩盘,先上图

先来描述一下缓存击穿的过程:

1.由于我们取数据的原则是先查询redis上,如果redis上有数据那么我们就取redis,如果没有则对数据库进行查询

2.当我们服务器压力变大(例如双十一购物)

3.而此时,我们的redis上大量的key过期,导致数据库压力剧增,返回给服务器的效率变低

4.由于效率变低,导致我们redis中缓存过多请求,导致redis崩溃

5.最终导致整个系统的崩盘

以上的过程就是雪崩

解决办法:

1.构建多级缓存(nginx缓存+redis缓存+其他缓存)

2.使用锁或者队列

3.设置过期标志自动更新

4.错开key的过期时间(建议3 4结合使用)

总结

1.redis妙用很多,需要在实际应用场景体会

2.思想很重要,基础也很重要

3.谢谢尚硅谷的老师

4.欢迎讨论指出错误

视频教程链接

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

(0)

相关推荐

  • Redis分布式锁防止缓存击穿的实现

    缓存击穿 和缓存穿透不同的是,缓存击穿是指:缓存中没有,但是数据库中存在的热点数据. 例如:首页的热点新闻,并发访问量非常大的热点数据,如果缓存过期失效,服务器会去查询DB,这时候如果大量的并发去查询DB,可能会瞬间压垮DB. 画了个简图,如下所示: 解决方案:DB查询加分布式锁. 未加锁的情况 解决问题之前,先看一下不做处理的代码和运行情况. 根据商品ID查询商品详情代码 清空Redis缓存,开启5个线程去并发访问测试,测试代码如下: 我们预期希望DB只查询一次,后面4个查询从Redis缓存中

  • 详解Java redis中缓存穿透 缓存击穿 雪崩三种现象以及解决方法

    目录 前言 一.缓存穿透 二.缓存击穿 三.雪崩现象 总结 前言 本文主要阐述redis中的三种现象 1.缓存穿透 2.缓存击穿 3.雪崩现象 本文主要说明本人对三种情况的理解,如果需要知道redis基础请查看其他博客,加油! 一.缓存穿透 理解:何为缓存穿透,先要了解穿透,这样有助于区分穿透和击穿,穿透就类似于伤害一点一点的累计,最终打到穿透的目的,类似于射手,一下一下普通攻击,最终杀死对方,先上图 先来描述一下缓存穿透的过程: 1.由于我们取数据的原则是先查询redis上,如果redis上有

  • 详解Java分布式系统中session一致性问题

    业务场景 在单机系统中,用户登陆之后,服务端会保存用户的会话信息,只要用户不退出重新登陆,在一段时间内用户可以一直访问该网站,无需重复登陆.用户的信息存在服务端的 session 中,session中可以存放服务端需要的一些用户信息,例如用户ID,所属公司companyId,所属部门deptId等等. 但是随着业务的发展,技术架构需要调整,原来的单机系统逐渐被更换,架构由单机扩展到分布式,甚至当下流行的微服务.虽然在用户端看来系统仍然是一个整体,但在技术端来说业务则被拆分成多个模块,各个模块之间

  • 详解JAVA Spring 中的事件机制

    说到事件机制,可能脑海中最先浮现的就是日常使用的各种 listener,listener去监听事件源,如果被监听的事件有变化就会通知listener,从而针对变化做相应的动作.这些listener是怎么实现的呢?说listener之前,我们先从设计模式开始讲起. 观察者模式 观察者模式一般包含以下几个对象: Subject:被观察的对象.它提供一系列方法来增加和删除观察者对象,同时它定义了通知方法notify().目标类可以是接口,也可以是抽象类或具体类. ConcreteSubject:具体的

  • 详解Java分布式系统中一致性哈希算法

    业务场景 近年来B2C.O2O等商业概念的提出和移动端的发展,使得分布式系统流行了起来.分布式系统相对于单系统,解决了流量大.系统高可用和高容错等问题.功能强大也意味着实现起来需要更多技术的支持.例如系统访问层的负载均衡,缓存层的多实例主从复制备份,数据层的分库分表等. 我们以负载均衡为例,常见的负载均衡方法有很多,但是它们的优缺点也都很明显: 随机访问策略.系统随机访问,缺点:可能造成服务器负载压力不均衡,俗话讲就是撑的撑死,饿的饿死. 轮询策略.请求均匀分配,如果服务器有性能差异,则无法实现

  • 详解Java String中intern方法的原理与使用

    目录 简介 常量池简介 intern方法简介(JDK7) 原理(JDK6与JDK7) 例程测试 例程分析 jdk1.6 jdk1.7 应用实例 简介 本文介绍Java的String的intern方法的原理. 常量池简介 在 JAVA 语言中有8种基本类型和一种比较特殊的类型String.这些类型为了使他们在运行过程中速度更快,更节省内存,都提供了一种常量池(在方法区)的概念.常量池就类似一个JAVA系统级别提供的缓存.8种基本类型的常量池都是系统协调的,String类型的常量池比较特殊. Str

  • 详解java代码中init method和destroy method的三种使用方式

    在java的实际开发过程中,我们可能常常需要使用到init method和destroy method,比如初始化一个对象(bean)后立即初始化(加载)一些数据,在销毁一个对象之前进行垃圾回收等等. 周末对这两个方法进行了一点学习和整理,倒也不是专门为了这两个方法,而是在巩固spring相关知识的时候提到了,然后感觉自己并不是很熟悉这个,便好好的了解一下. 根据特意的去了解后,发现实际上可以有三种方式来实现init method和destroy method. 要用这两个方法,自然先要知道这两

  • 详解Java集合中的基本数据结构

    集合中三大数据结构 数组 内存地址连续 可以通过下标的成员访问,下标访问的性能高 增删操作有较大的性能消耗(需要动态扩容) 链表(双向链表) 灵活的空间要求,存储空间不要求连续 不支持下标访问,支持顺序遍历搜索 针对增删操作找到对应的节点改变链表的头尾指针指向即可,无需移动元数据存储位置 树(Java中二叉树特性) 某节点的左子树节点仅包含小于该节点的值 某节点的右子树节点仅包含大于该节点的值 节点必须是二叉树 顺序排列 存在问题:树可以认为是介于数组和链表二者之间的一种数据结构,拥有较快的查询

  • 详解Java设计模式中的装饰模式

    目录 一.装饰模式的定义和特点 二.装饰模式的结构 三.咖啡点单案例演示 四.总结 一.装饰模式的定义和特点 在软件开发过程中,有时想用一些现存的组件.这些组件可能只是完成了一些核心功能.但在不改变其结构的情况下,可以动态地扩展其功能.所有这些都可以釆用装饰器模式来实现. 就像我们做菜,需要用到调料,菜,刀,火等一系列抽象的组件来最终完成一道菜. 装饰模式的定义: 指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式.就增加功能来说,装饰模式

  • 详解Java泛型中类型擦除问题的解决方法

    以前就了解过Java泛型的实现是不完整的,最近在做一些代码重构的时候遇到一些Java泛型类型擦除的问题,简单的来说,Java泛型中所指定的类型在编译时会将其去除,因此List 和 List 在编译成字节码的时候实际上是一样的.因此java泛型只能做到编译期检查的功能,运行期间就不能保证类型安全.我最近遇到的一个问题如下: 假设有两个bean类 /** Test. */ @Data @NoArgsConstructor @AllArgsConstructor public static class

  • 一文详解Java线程中的安全策略

    目录 一.不可变对象 二.线程封闭 三.线程不安全类与写法 四.线程安全-同步容器 1. ArrayList -> Vector, Stack 2. HashMap -> HashTable(Key, Value都不能为null) 3. Collections.synchronizedXXX(List.Set.Map) 五.线程安全-并发容器J.U.C 1. ArrayList -> CopyOnWriteArrayList 2.HashSet.TreeSet -> CopyOnW

随机推荐