一、前言

二、缓存

2.1 缓存本质 + 缓存分类 + 缓存三大特征 + 三种淘汰算法 + 根据业务场景设计过期时间

缓存本质：一个数据模型对象。
缓存作用（一句化小结）：解决 软件响应速度要求快 和 数据库中查找速度慢 的问题。
缓存分为本地缓存和分布式缓存两种（分级缓存就是应用缓存+分布式缓存）：
分布式缓存（即进程间缓存）如redis、memcached等，
本地缓存（即进程内缓存）如ehcache、GuavaCache、Caffeine等。

缓存三大特征
第一特征，命中率
定义：命中率=命中数/（命中数+没有命中数）当某个请求能够通过访问缓存而得到响应时，称为缓存命中。缓存命中率越高，缓存的利用率也就越高。
第二特征，最大空间
定义：最大空间表示缓存中可以容纳最大元素的数量。当缓存存放的数据超过最大空间时，就需要根据淘汰算法来淘汰部分数据存放新到达的数据。
第三特征，淘汰算法
定义：缓存的存储空间有限制，当缓存空间被用满时，要求保证在稳定服务的同时有效提升命中率，这就由缓存淘汰算法来处理，设计适合自身数据特征的淘汰算法能够有效提升缓存命中率。

三种淘汰算法：业务驱动技术，如何选择淘汰算法
FIFO(first in first out) 先进先出
定义：最先进入缓存的数据在缓存空间不够的情况下（超出最大元素限制）会被优先被清除掉，以腾出新的空间接受新的数据。
比较的对象：策略算法主要比较缓存元素的创建时间。
业务场景：适用于保证高频数据有效性场景，优先保障最新数据可用。
LFU(less frequently used)「最少使用」
定义：无论是否过期，仅根据元素的被使用次数判断，清除使用次数较少的元素释放空间。
比较的对象：策略算法主要比较元素的hitCount（命中次数）。
业务场景：适用于保证高频数据有效性场景。
LRU(least recently used)「最近最少使用」
定义：无论是否过期，仅根据元素最后一次被使用的时间戳，清除最远使用时间戳的元素释放空间。
比较的对象：策略算法主要比较元素最近一次被get使用时间。
业务场景：比较适用于热点数据场景，优先保证热点数据的有效性。

关于缓存：业务驱动技术，如何设置过期时间，以一个飞机票订单为例
比如实际工作中我们对于订单详情的一个缓存。我们可能会根据订单的状态来来构建缓存。
第一，对于已出行、或者已经取消的订单我们基本上是不会去管的（因为订单状态已经终止了，不会再有对于订单状态的写请求），
1.1 对于订单读操作：实时性要求没那么高，从缓存中拿
所以，对于这种订单我们设置的过期时间是不是就可以久一点，比如7天或者30天。
第二，对于未出行即将起飞的订单，这时候顾客是不是就会频繁的去刷新订单看看，看看有没有晚点什么的，或者登机口是在哪。
2.1 对于读操作：实时性要求没那么高，从缓存中拿
2.2 对于订单写操作，需要更改订单的状态的（比如退票、改签），可以直接不走缓存，直接查询并修改数据库。
一般来说，读多写少。
所以，对于这种实时性要求比较高的订单我们过期时间还是要设置的比较短的。

2.2 本地缓存（进程内缓存）

本地缓存定义：应用和缓存都在同一个进程里面，
本地缓存优点：获取缓存数据的时候纯内存操作，没有额外的网络开销，速度非常快。
本地缓存缺点：
本地缓存与业务系统耦合在一起，应用之间无法直接共享缓存的内容。需要每个应用节点单独的维护自己的缓存。每个节点都需要一份一样的缓存，对服务器内存造成一种浪费。本地缓存机器重启、或者宕机都会丢失。
本地缓存存放不可变数据：它适用于缓存一些应用中基本不会变化的数据，比如（国家、省份、城市等），一般可以在应用启动的时候，把需要的数据加载到系统中。

本地缓存三种更新缓存的方式
更新缓存1-定时变量更新（实时性不高）：在应用中起一个定时任务（「ScheduledExecutorService」、「TimerTask」等），让它每隔多久去加载变更（数据变更之后可以修改数据库最后修改的时间，每次查询变更数据的时候都可以根据这个最后变更时间加上半小时大于当前时间的数据）的数据重新到缓存里面来。
更新缓存2-定时全量更新（实时性不高）：如果觉得这个定时变量更新比较最后修改时间戳麻烦，可以使用全量更新（就跟项目启动加载数据一样）。这种方式的话，对数据更新可能会有点延迟。可能这台机器看到的是更新后的数据，那台机器看到的数据还是老的（机器发布时间可能不一样）。
无论是定时变量更新还是定时变量更新，实时性都不高，所以有了广播订阅mq消息更新。
更新缓存3-广播订阅mq消息（实时性高）：如果对实时性有要求的话，使用广播订阅mq消息更新。一旦有数据更新mq会把更新数据推送到每一台机器，实时性好，但是实现起来较为复杂。
小结：本地缓存实时性排名：广播订阅mq消息更新>定时变量更新>定时全量更新。

本地缓存举例

常见本地缓存有以下几种实现方式：从上述表格我们看出性能最佳的是Caffeine。实际开发中，关于这个本地缓存作为整个多级缓存系统的一部分，里面提供了丰富的api，以及各种各样的淘汰算法。

2.3 分布式缓存

分布式缓存
分布式缓存定义：与应用分离的缓存组件或服务，其最大的优点是自身就是一个独立的应用，与本地应用隔离，多个应用可直接的共享缓存。
分布式缓存举例：常见的分布式缓存有redis、MemCache等。
分布式缓存的应用：
在高并发的环境下，比如春节抢票大战，一到放票的时间节点，分分钟大量用户以及黄牛的各种抢票软件流量进入12306，这时候如果每个用户的访问都去数据库实时查询票的库存，大量读的请求涌入到数据库，瞬间Db就会被打爆，cpu直接上升100%，服务马上就要宕机或者假死。即使进行了分库分表也是无法避免的。为了减轻db的压力以及提高系统的响应速度。一般都会在数据库前面加上一层缓存，甚至可能还会有多级缓存。

2.4 缓存雪崩 + 缓存穿透 + 缓存击穿 + 缓存更新

缓存雪崩
定义：指大量缓存同一时间段集体失效，或者缓存整体不能提供服务，导致大量的请求全部到达数据库 对数据CPU和内存造成巨大压力，严重的会造成数据库宕机。因此而形成的一系列连锁反应造成整个系统奔溃。
解决方式：
第一，保证缓存的高可用。
优点：使用redis的集群模式，即使个别redis节点下线，缓存还是可以用。一般稍微大点的公司还可能会在多个机房部署Redis。这样即使某个机房突然停电，或者光纤又被挖断了，这时候缓存还是可以使用。
第二，使用多级缓存（本地缓存 + 分布式缓存，推荐方式）。
优点：不同级别缓存时间过时时间不一样，即使某个级别缓存过期了，还有其他缓存级别 兜底。比如我们Redis缓存过期了，我们还有本地缓存。这样的话即使没有命中redis，有可能会命中本地缓存。
第三，缓存永不过期。
优点：缓存永不过期，就不会发生缓存雪崩。
缺点：会浪费更多的存储空间，一般应该也不会推荐这种做法。
第四，使用随机过期时间（推荐方式）。
优点：为每一个key都合理的设计一个过期时间，这样可以避免大量的key在同一时刻集体失效；
第五，异步重建缓存。
优点：缓存永不过期，就不会发生缓存雪崩。
缺点：需要维护每个key的过期时间，定时去轮询这些key的过期时间。例如一个key的value设置的过期时间是30min，那我们可以为这个key设置它自己的一个过期时间为20min。所以当这个key到了20min的时候我们就可以重新去构建这个key的缓存，同时也更新这个key的一个过期时间。

缓存穿透（电商：伪造不存在的订单号）
定义：指查询一个不存在的数据，每次通过接口或者去查询数据库都查不到这个数据，比如黑客的恶意攻击，比如知道一个订单号后，然后就伪造一些不存在的订单号，然后并发来请求你这个订单详情。这些订单号在缓存中都查询不到，然后会导致把这些查询请求全部打到数据库或者SOA接口。这样的话就会导致数据库宕机或者你的服务大量超时。这种查询不存在的数据就是缓存穿透。解决这个问题可以从以下方面入手：
第一，缓存空值
对于这些不存在的请求，仍然给它缓存一个空的结果，这种方式简单粗暴，但是如果后续这个请求有新值了需要把原来缓存的空值删除掉（所以一般过期时间可以稍微设置的比较短）。
第二，使用布隆过滤器
查询缓存之前先去布隆过滤器查询下这个数据是否存在。如果数据不存在，然后直接返回空。这样的话也会减少底层系统的查询压力。
第三，缓存找不到直接返回
这种方式的话要根据自己的实际业务来进行选择。比如固定的数据，一些省份信息或者城市信息，可以全部缓存起来，对于这些省份和城市信息，都在缓存里面，根本不用访问数据库，缓存找不到，直接返回，避免缓存穿透攻击。

缓存击穿
定义：是指缓存里面的一个热点key(拼多多的五菱宏光神车的秒杀)在某个时间点过期。针对于这一个key有大量并发请求过来然后都会同时去数据库请求数据，瞬间对数据库造成巨大的压力。
解决方式：
第一，缓存永不过期。
优点：缓存永不过期，就不会发生缓存击穿；
缺点：会浪费更多的存储空间，一般应该也不会推荐这种做法。
第二，异步重建缓存。
优点：缓存永不过期，就不会发生缓存击穿。
缺点：这样的话需要维护每个key的过期时间，定时去轮询这些key的过期时间。例如一个key的value设置的过期时间是30min，那我们可以为这个key设置它自己的一个过期时间为20min。所以当这个key到了20min的时候我们就可以重新去构建这个key的缓存，同时也更新这个key的一个过期时间。
第三，互斥锁重建缓存。
前提条件：只能针对于同一个key的情况下，比如你有100个并发请求都要来取A的缓存，这时候我们可以借助redis分布式锁来构建缓存，让只有一个请求可以去查询DB其他99个（没有获取到锁）都在外面等着，等A查询到数据并且把缓存构建好之后其他99个请求都只需要从缓存取就好了。原理就跟我们java的DCL（double checked locking）思想有点类似。

缓存更新
我们一般的缓存更新主要有以下几种更新策略：
1、先更新缓存，再更新数据库
2、先更新数据库，再更新缓存
3、先删除缓存，再更新数据库
4、先更新数据源库，再删除缓存（推荐）
至于选择哪种更新策略的话，没有绝对的选择，可以根据自己的业务情况来选择适合自己的不过一般推荐的话是选择 「先更新数据源库，再删除缓存」。

三、限流（服务限流，表示处理的对象是服务，包括限流四规则 + 限流四实现）

3.1 限流

限流定义
限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

为什么要限流？一句话小结：为了保证系统的稳定运行。
假设我们一个系统一小时之最多只能处理10000个请求，但是一小时流量突增10倍，这突增的流量我们如果不进行限制的话，任由它直接进入系统的话，是不是直接会把我们的系统弄瘫痪，就无法对外提供服务了。
金手指：高并发的五种措施，缓存、限流、降级、熔断、隔离都是保护系统的稳定运行

3.2 限流四规则

限流四个规则，
（要记忆，语言已组织好）既然要限流，就是要允许一部分请求进入，阻止另外一部分请求进入，那么根据什么规则来筛选进入的请求和被拒绝的请求呢（即提供什么规则决定谁去好大学，谁去差大学，就是高考）？提供四种：
1、后端不做任何干涉，完全交给不确定的网络，先达到的请求先处理，后达到的请求后处理，达到阈值直接拒绝服务；
2、后端对服务分级，对于核心服务的请求就处理，对于非核心的请求的服务不处理，又称服务的主动降级；
3、后端所有请求都处理，但是放到延迟队列中，一点一点的处理。
4、后端对用户分级，对于重要用户的请求优先处理，对于普通用户的请求普通处理，这就是限流规则。
第一种限流，达到阈值直接拒绝服务，实现限流，最简单的限流，这种限流方式实现简单，但是要求阈值设置合理，
这个是最最简单粗暴的做法了，直接把请求直接拒绝掉。比如早高峰坐地铁的时候，直接让进入1000个人，剩下多出来的人不让坐地铁了。直接把入站口给关闭了。
第二种限流，服务降级，实现限流，核心：服务分级
将系统的所有功能服务进行一个分级，当系统出现问题，需要紧急限流时，可将不是那么重要的功能进行降级处理，停止服务，这样可以释放出更多的资源供给核心功能的去用。比如：有一个功能新用户注册完，要给用户发送多少优惠券。这时候服务降级的话就可以直接把送券服务关掉，让服务快速响应，提高系统处理能力。
第三种限流，请求放到队列种，延迟处理，实现限流，核心：队列
把请求全部放入到队列中，真正处理的话，就从队列里面依次去取，这样的话流量比较大的情况可能会导致处理不及时，会有一定的延时。双十一零点我们付款的时候，去查询订单的状态是不是也会有一定的延时，不像在平时付完款订单状态就变成了付款状态。
第四种限流，特权处理，实现限流，核心：用户分级
这个模式需要将用户进行分类，通过预设的分类，让系统优先处理需要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理。我们去银行办理业务的时候是不是也会经常需要排队，但是是不是经常会VIP用户、什么白金卡用户，直接不需要排队，直接一上来就可以办理业务，还优先处理这些人的业务。是不是特羡慕这些人,哎 羡慕也没办法谁叫人家有钱咧。
金手指：第二种和第四种都是分级，有什么不同？
回答：分级的对象不同。第二种是服务分级，即对事不对人，对不重要的服务限流；第四种是用户分级，即对人不对事，对不重要的用户限流。

3.3 限流四实现

三种限流组件、三种限流实现方式
第一种，计数器方法(达到阈值直接拒绝访问)
这是最简单的限流算法了，系统里面维护一个计数器，来一个请求就加1，请求处理完成就减1，当计数器大于指定的阈值，就拒绝新的请求。是通过全局的总求数于设置的阈值来达到限流的目的。通常应用在池化技术上面比如：「数据库连接池、线程池」等中应用。这种方式的话限流不是「平均速率」的。扛不住突增的流量。
第二种，滑动窗口算法
一种常见的流量控制技术,用来改善吞吐量的技术

第三种，漏桶算法

上图，水是可以持续流入漏桶里面的（即所有请求一定会经过漏桶的过滤），底部也是匀速的流出，如果漏桶的水超过桶的大小就会发生益出（即 流入的速率大于底部流出的速率 + 持续一段时间后）。
重点：两个速率：
流入速率即实际的用户请求速率或压力测试的速率，流出速率即服务端处理速率。
一般来说，流出速度是固定的，即不管你请求有多少，速率有多快，我反正就这么个速度处理。当然，特殊情况下，需要加快速度处理，也可以动态调整流出速率。
第四种，令牌桶

上图解释：如果令牌的数量超过里桶的限制的话，令牌就会溢出，这时候就直接舍弃多余的令牌。
每个请求过来必须拿到桶里面拿到了令牌才允许请求（拿令牌的速度是不限制的，这就意味着如果瞬间有大量的流量请求进来，可以短时间内拿到大量的令牌），拿不到令牌的话直接拒绝。这个令牌桶的思想是不是跟我们java里面的「Semaphore」 有点类似。Semaphore 是拿信号量，用完了就还回去。但是令牌桶的话，不需要还回去，因为令牌会定时的补充。令牌桶算法我们可以通过
Google开源的guava包创建一个令牌桶算法的限流器。
金手指：令牌桶和漏桶不同点：令牌桶新增了一个匀速生产令牌的中间人以恒定的速度往桶里面放令牌，上面的漏桶，流入速率根本不控制，用户请求压力直接达到漏桶来（令牌桶这个匀速流入速率和mq对于mysql请求量的控制很像）。
以上是三种限流组件，大家可以根据这个思想然后去实现各种各样的限流组件。

金手指：任何限流组件都要设置阈值
第一，不管是哪种限流方法，直接拒绝也要，漏桶、令牌桶也好，限流算法里面一定有一个阈值（解释：直接拒绝要设置阈值，漏桶令牌桶要设置桶大小），这个阈值设置为多少是不是比较难。阈值设置过大的话，服务可能扛不住，阈值设置小了会把用户请求给误杀，资源没有得到最大的一个利用。
第二，任何限流组件都要设置阈值，这是限流和其他两种保护系统稳定运行的方式（降级、熔断）的最大区别，即限流一定要好设置阈值。

四、降级（即服务降级，表示处理的对象是服务，这里指主动降级）

4.1 服务降级的定义

服务降级的定义：
服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。
来源于百度百科。这些话看起来是不是不是很好理解，那么我们可以举个栗子：双十一的时候，我们买东西是不是都不允许修改购物地址，不允许发起退货，不允许退款还有很多服务都不可以用，只允许用户选择商品加入购物车付钱。那天只有一个目的就是让一些不是很重要的服务所占用的cpu资源都让出来，给购物，付款这样的核心服务。这样的话，用户付款的速度就会越来越快，毕竟前多少名支付的用户是有免单机会的（大家都会挤在0点那一刻去付款）。服务降级主要用于当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。 降级就是为了解决资源不足和访问量增加的矛盾。

4.2 服务降级五种方式

服务降级方式
第一，延迟服务：定时任务处理、或者mq延时处理。比如新用户注册送多少优惠券可以提示用户优惠券会24小时到达用户账号中，我们可以选择再凌晨流量较小的时候，批量去执行送券。
第二，被动降价，前端页面降级：页面点击按钮全部置灰，或者页面调整成为一个静态页面显示“系统正在维护中，。。。。”。
第三，主动降级，关闭非核心服务：比如电商关闭推荐服务、关闭运费险、退货退款等。保证主流程的核心服务下单付款就好。
第四，写降级：比如秒杀抢购，我们可以只进行Cache的更新返回，然后通过mq异步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。
第五，读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景。

五、熔断（即服务熔断，表示处理的对象是服务，就是被动降级）

5.1 服务雪崩

服务雪崩
说到服务熔断我们就得先了解下什么是服务雪崩。雪崩效应好比就是蝴蝶效应，说的都是一个小因素的变化，却往往有着无比强大的力量，以至于最后改变整体结构、产生意想不到的结果。 多个微服务之间调用的时候，比如A服务调用了B服务，B服务调用了C服务，然后C服务由于机器宕机或者网略故障， 然后就会导致B服务调用C服务的时候超时，然后A服务调用B服务也会超时，最终整个链路都不可用了，导致整个系统不可用就跟雪蹦一样。

5.2 服务雪崩产生的原因

雪崩效应产生的几种场景
1、突增流量：比如一大波爬虫，或者黑客攻击等。
2、程序bug：代码死循环，或者资源未释放等。
3、硬件原因：机器宕机、机房断电、光纤被挖断等。

5.3 熔断机制是应对雪崩效应的一种微服务链路保护机制

熔断机制是应对雪崩效应的一种微服务链路保护机制，在互联网系统中当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，暂时不再继续调用目标服务，直接快速返回失败标志，快速释放资源。如果目标服务情况好转则恢复调用。

六、面试金手指

6.1 限流四规则 + 限流四实现

限流四个规则，
（要记忆，语言已组织好）既然要限流，就是要允许一部分请求进入，阻止另外一部分请求进入，那么根据什么规则来筛选进入的请求和被拒绝的请求呢（即提供什么规则决定谁去好大学，谁去差大学，就是高考）？提供四种：
1、后端不做任何干涉，完全交给不确定的网络，先达到的请求先处理，后达到的请求后处理，达到阈值直接拒绝服务；
2、后端对服务分级，对于核心服务的请求就处理，对于非核心的请求的服务不处理，又称服务的主动降级；
3、后端所有请求都处理，但是放到延迟队列中，一点一点的处理。
4、后端对用户分级，对于重要用户的请求优先处理，对于普通用户的请求普通处理，这就是限流规则。

限流四实现
1、第一种，计数器方法(达到阈值直接拒绝访问)
2、第二种，滑动窗口算法，用于改善吞吐量技术
3、第三种，漏桶算法：流入速率即实际的用户请求速率或压力测试的速率，流出速率即服务端处理速率。如果漏桶的水超过桶的大小就会发生益出（即 流入的速率大于底部流出的速率 + 持续一段时间后）。
4、第四种，令牌桶
金手指：令牌桶和漏桶不同点：令牌桶新增了一个匀速生产令牌的中间人以恒定的速度往桶里面放令牌，上面的漏桶，流入速率根本不控制，用户请求压力直接达到漏桶来（令牌桶这个匀速流入速率和mq对于mysql请求量的控制很像）。

金手指：任何限流组件都要设置阈值
第一，不管是哪种限流方法，直接拒绝也要，漏桶、令牌桶也好，限流算法里面一定有一个阈值（解释：直接拒绝要设置阈值，漏桶令牌桶要设置桶大小），这个阈值设置为多少是不是比较难。阈值设置过大的话，服务可能扛不住，阈值设置小了会把用户请求给误杀，资源没有得到最大的一个利用。
第二，任何限流组件都要设置阈值，这是限流和其他两种保护系统稳定运行的方式（降级、熔断）的最大区别，即限流一定要好设置阈值。

6.2 五种措施小结

起手式，五种措施的总体比较，拉高逼格
第一，五种措施目的相同：都是保护系统稳定运行；
第二，接上面，为了达到系统稳定运行的目的
2.1 三种措施终表现类似：限流降级熔断，为了达到维护系统稳定运行的目的，最终让用户体验到的是某些功能暂时不可达或不可用；
2.2 其他两种方式，为了达到系统稳定运行的目的，缓存使用多级缓存（本地缓存+分布式缓存）加快速度达到这个目的；隔离通过设计低耦合后端系统达到这个目的，mysql分库低耦合，mq分业务低耦合，redis集群低耦合，微服务框架低耦合，nginx业务集群低耦合。
第三，接上面，三种措施粒度一般都是服务级别：限流降级熔断，粒度一般都是服务级别
隔离在设计上也是服务级别的，服务与服务之间隔离，构建微服务系统，对于其他资源，mysql、mq redis nginx 都是业务模块级别隔离，也可以细粒度隔离，放到不同服务器上，比如mysql业务模块的库级别隔离，可以更加细粒度表级别隔离。

第二，金手指（缓存 + 限流 + 降级 VS 熔断 + 隔离） 一句话小结
缓存 + 限流 + 降级 立足与单个服务，是为了保证单个服务，单个热点服务不要发生宕机；
熔断和隔离 立足与服务间关系，是保证单个服务发生宕机后，不要影响或尽可能小的影响其他服务；进一步阐述熔断和隔离，隔离是服务宕机前，系统启动前，服务设计和资源设计，一种设计思想，服务间低耦合的设计思想，包括资源和调用的低耦合，mysql分库低耦合，mq分业务低耦合，redis集群低耦合，微服务框架低耦合，nginx业务集群低耦合；熔断是服务宕机后，该服务及调用该服务的服务，熔断，下一请求快速失败，如hystrix。

第三，限流 和其他四者区别
定义：限流：根据一定规则阻挡，阈值是事先设定好的。
不同点：限流，被阻挡的请求没有被抛弃了；降级（主动降级），被降级的服务暂时无法访问。
被动降级即熔断，被阻挡的请求直接熔断失败。
缓存和隔离与具体实际请求无关

第四，金手指 熔断（熔断和四种区别）
第一，缓存、限流、降级、隔离是在设计为了尽量避免服务发生异常，熔断是指服务发生异常后，将损害降低到最小。
第二，自治性要求很高: 熔断模式一般都是服务基于策略的自动触发，其他的，缓存、限流、降级、隔离是人工干预。
第三，触发原因不同：熔断一般是某个具体服务（下游服务）故障引起，而缓存、限流、降级、隔离一般是从整体负荷考虑；
第四，管理目标的层次不同：熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而缓存、限流、降级、隔离一般需要对业务有层级之分（比如降级一般是从最外围服务开始）。

主动降级和被动降级
降级是主动降级，降低非核心服务级别，熔断是被动降级，降低当前宕机服务级别，让其快速失败

七、小结

高并发五个利器（缓存、限流、降级、熔断、隔离），结束了。

天天打码，天天进步！！！