雪崩

本文链接： https://blog.csdn.net/kongtiao5/article/details/82771694 一、缓存处理流程 前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。 二、缓存穿透 描述： 缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。 解决方案： 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截； 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击 三、缓存击穿 描述： 缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力 解决方案： 设置热点数据永远不过期。 加互斥锁，互斥锁参考代码如下： 说明： 1）缓存中有数据，直接走上述代码13行后就返回结果了 2）缓存中没有数据，第1个进入的线程，获取锁并从数据库去取数据，没释放锁之前

1. 什么是Redis Redis是由意大利人Salvatore Sanfilippo（网名：antirez）开发的一款内存高速缓存数据库。Redis全称为：Remote Dictionary Server（远程数据服务），该软件使用C语言编写，Redis是一个key-value存储系统，它支持丰富的数据类型，如：string、list、set、zset(sorted set)、hash。 2. Redis特点 以内存作为数据存储介质，读写数据的效率极高，远远超过数据库。以设置和获取一个256字节字符串为例，它的读取速度可高达110000次/s，写速度高达81000次/s。 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。 支持多种数据类型String、List、Hash、Set、zset 支持数据的备份，即master-slave模式的数据备份 3.Redis有哪些数据类型，以及每种数据类型使用的场景 Redis支持多种数据类型，有String、List、Hash、Set、zset String(字符串) String类型是二进制安全的，意思是Redis的String可以包含任何数据，比如图片或者序列化的对象等。一个Redis中字符串的value最多可以是512M。一般做一些复杂的计数功能的缓存。 List(列表)

缓存穿透： 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且处于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决办法： 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用 布隆过滤器 ，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们 仍然把这个空结果进行缓存 ，但它的过期时间会 很短 ，最长不超过五分钟。 缓存雪崩 缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过大雪崩。 解决方案： 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以 在原有的失效时间基础上增加一个随机值，比如1-5分钟随机 ，这样每一个缓存的过期时间的重复率就会降低

缓存穿透 缓存系统，按照 KEY 去查询 VALUE, 当 KEY 对应的 VALUE 一定不存在的时候并对 KEY 并发请求量很大的时候，就会对后端造成很大的压力。 如何避免 1. 对查询机构为空的情况也进行缓存，缓存的时间设置端一点，或者对该 KEY 对应的数据 insert 之后清理缓存。 2. 对一定不存在的 key 进行过滤，可以把所有存在的 key 放到一个大 bitmap 中，查询时通过该 bitmap 过滤。 缓存雪崩 分布式缓存系统面临的问题 缓存一致性问题 1 ：缓存系统与底层数据的一致性。这点在底层系统是“可读可写”时，写得尤为重要 2 ：有继承关系的缓存之间的一致性。为了尽量提高缓存命中率，缓存也是分层：全局缓存，二级缓存。他们是存在继承关系的。全局缓存可以有二级缓存来组成。 3 ：多个缓存副本之间的一致性。为了保证系统的高可用性，缓存系统背后往往会接两套存储系统（如 memcache ， redis 等） 缓存穿透和缓存雪崩 上面有讲述。 缓存数据的淘汰 缓存淘汰的策略有两种： (1) 定时去清理过期的缓存。 （ 2 ）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣，第一种的缺点是维护大量缓存的 key 是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂

缓存雪崩与缓存穿透 今天来分享一下Redis几道常见的面试题： 如何解决缓存雪崩？ 如何解决缓存穿透？ 如何保证缓存与数据库双写时一致的问题？ 一、缓存雪崩 1.1 什么是缓存雪崩？ 首先我们先来回答一下我们为什么要用缓存(Redis)： 1、提高性能能：缓存查询是纯内存访问，而硬盘是磁盘访问，因此缓存查询速度比数据库查询速度快 2、提高并发能力：缓存分组了部分请求，支持更高的并发 现在有个问题， 如果我们的缓存挂掉了，这意味着我们的全部请求都跑去数据库了 。 我们都知道Redis不可能把所有的数据都缓存起来( 内存昂贵且有限 )，所以Redis需要对数据设置过期时间，将已经过期的键值对删除，它采用的是惰性删除+定期删除两种策略对过期键删除。 如果缓存数据 设置的过期时间是相同 的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存 同时失效 ，全部请求到数据库中。 这就是缓存雪崩 ： Redis挂掉了，请求全部走数据库。 对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。 缓存雪崩如果发生了，很可能就把我们的数据库 搞垮 ，导致整个服务瘫痪！ 1.2 如何解决缓存雪崩？ 对于“对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。”这种情况，非常好解决： 解决方法：在缓存的时候给过期时间加上一个 随机值

Redis缓存穿透和缓存雪崩解决方案 redis的缓存有哪些问题？一致性？击穿？雪崩等是如何解决的？ 缓存穿透 ：是指查询一个一定不存在的数据。由于缓存命不中时会去查询数据库，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。 解决方案： 1.是将空对象也缓存起来，并给它设置一个很短的过期时间，最长不超过5分钟​2.采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力 雪崩 ：如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，就会造成缓存雪崩。 解决方案： 1.尽量让失效的时间点不分布在同一个时间点 2.保证缓存层服务的高可用，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，比如 Redis Sentinel 和 Redis Cluster 都实现了高可用。 缓存击穿 ：是指一个key非常热点，在不停的扛着大并发，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。 解决方案： 可以设置key永不过期 来源： https://www.cnblogs.com/-courage/p/11559503.html

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代

缓存的收益和成本 1、缓存带来的回报 高速读写 ：缓存加速读写速度：CPU L1/L2/L3 Cache、Linux page Cache加速硬盘读写、浏览器缓存、Ehcache缓存数据库结果 降低后端负载 ：后端服务器通过前端缓存降低负载： 业务端使用Redis降低后端MySQL负载等 2、缓存带来的代价 数据不一致： 缓存层和数据层有时间窗口不一致，和更新策略有关 代码维护成本：原本只需要读写MySQL就能实现功能，但加入了缓存之后就要去维护缓存的数据，增加了代码复杂度。 堆内缓存可能带来内存溢出的风险影响用户进程，如ehCache、loadingCache： 堆内缓存是由jvm分配的缓存 jvm运行时数据区：堆、java虚拟机栈、方法区、本地方法栈、程序计数器 堆内缓存和远程服务器缓存redis的选择 堆内缓存一般性能更好，远程缓存需要套接字传输 用户级别缓存尽量采用远程缓存 大数据量尽量采用远程缓存，服务节点化原则 redis的特性 redis有哪些特性 丰富的数据类型 可用于缓存，消息按key设置过期时间，过期后自动删除 setex set expire时间 支持持久化方式rdb和aof 主从分布式，redis支持主从支持读写分离 redis cluster，动态扩容方式。 你用过redis的哪几种特性 用sorted Set实现过排行榜项目

一、常见概念 击穿： 概念：redis作为缓存，设置了key的过期时间，key在过期的时候刚好出现并发访问，直接击穿redis，访问数据库 解决方案：使用setnx() ->相当于一把锁，设置的时候，发现设置过期，加锁，只有获得锁的人才可以访问DB，这样就能防止击穿。 逻辑： 1. get key 2. setnx 3. if ok addDB else sleep go to 1 question1：如果第一个加锁的人挂了？ 可以设置过期时间 question2：如果第一个加锁的人没挂，但是锁超时了？ 可以使用多线程，一个线程取库，一个线程监控前一个线程是否存活，更新锁时间。 穿透： 概念：从业务接收查询的是你系统根本不存在的数据，这时候刚好从redis穿透到数据 解决方案： 使用布隆过滤器，不存在的数据使用bitmap进行拦截 1.使用布隆过滤器。从客户端包含布隆过滤器的算法。 2.直接redis集成布隆模块。 question1:布隆过滤器只能查看，不能删除？解决方案：换cuckoo过滤器。 雪崩： 概念：大量的key同时失效，造成雪崩。 解决方案：在失效的基础上，再加入一个时间（1-5min） 二、SpringDataRedis 客户端连接，我们可以使用Jedis、lettuce、redisson...但是，我们在技术选型时，鉴于多方面考虑

一、雪崩效应 　　在微服务架构中，由于服务和服务之间可以互相调用，一项工作的完成可能会依赖调用多个微服务模块，但由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪；再加上服务和服务之间的依赖性，瘫痪会迅速传播，给整个微服务系统造成严重的后果，这就是服务故障的“血崩”效应。 服务雪崩效应形成的阶段 1、服务提供者不可用 硬件故障。硬件损坏导致服务器主机宕机，或网络硬件故障造成服务提供者的不可访问。 程序Bug 缓存击穿。一般发生在缓存应用重启，所有缓存被清空时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端，造成服务提供者超负荷运行，引起服务不可用。 用户大量请求 2、重试加大流量 用户重试 代码逻辑重试 3、服务调用者不可用 同步等待造成资源耗尽。同步调用时，产生大量的等待线程占用系统资源。 二、服务雪崩的应对措施 针对造成服务雪崩的不同原因，可以采用不同的应对措施。 1、流量控制 网关限流 用户交互限流，例如：1.采用加载动画，提高用户的忍耐等待时间。2.提交按钮添加强制等待机制等。 关闭重试 2、改进缓存模式 缓存预加载 同步改为异步刷新 3、服务自动扩容 AWS的auto scaling 4、服务调用者降级服务 资源隔离