当我们的系统的访问量突然剧增，大量的请求涌入过来，最典型的就是秒杀业务了，我们可能会知道会有一波高峰，这时候该如何处理？ 而且现在很多情况我们还需要调用第三方接口例如支付等，因此我们还得考虑如果第三方那边出问题了，返回异常的慢，我们系统该如何处理。

常见的处理方式有三种：降级、熔断、限流。

降级

降级也就是服务降级，当我们的服务器压力剧增为了保证核心功能的可用性，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。

就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。

降级牺牲的是什么

强强一致性变成最终一致性

大多数的系统是不需要强一致性的。

强一致性就要求多种资源的占用，减少强一致性就能释放更多资源

这也是我们一般利用消息中间件来削峰填谷，变强一致性为最终一致性，也能达到效果

干掉一些次要功能

停止访问不重要的功能，从而释放出更多的资源

举例来说，比如电商网站，评论功能流量大的时候就能停掉，当然能不直接干掉就别直接，最好能简化流程或者限流最好

降级的注意点

对业务进行仔细的梳理和分析

哪些是核心流程必须保证的，哪些是可以牺牲的

什么指标下能进行降级

吞吐量、响应时间、失败次数等达到一个阈值才进行降级处理

如何降级

降级最简单的就是在业务代码中配置一个开关或者做成配置中心模式，直接在配置中心上更改配置，推送到相应的服务。

熔断

我们家用电闸上都有保险丝模块，当电压出现短路问题时，自动跳闸，此刻电路主动断开，我们的电器就会收到保护。否则，不能断开，后果不堪设想。

保险丝就是一个自我保护装置，保护整个电路。

降级一般而言指的是我们自身的系统出现了故障而降级。而熔断一般是指依赖的外部接口出现故障的情况断绝和外部接口的关系。

例如你的A服务里面的一个功能依赖B服务，这时候B服务出问题了，返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能，因此我们这时候就需要熔断！即当发现A要调用这B时就直接返回错误(或者返回其他默认值啊啥的)，就不去请求B了。我这还是举了两个服务的调用，有些那真的是一环扣一环，出问题不熔断，那真的是会雪崩。

当然也有人认为熔断不就是降级的一种的，我觉得你非要说熔断也属于一种降级我也没法反驳，但是它们本质上的突出点和想表达的意思还是有一些不同的。

那什么时候熔断合适呢？也就是到达哪个阈值进行熔断，5分钟内50%的请求都超过1秒？还是啥？参考降级。

限流

上面说的两个算是请求过来我们都受理了，这个限流就更狠了，直接跟请求说对不起再见！也就是系统规定了多少承受能力，只允许这么些请求能过来，其他的请求就说再见了。

一般限制的指标有：请求总量或某段时间内请求总量。

限流有哪些行为

拒绝服务

最简单的方式，把多余的请求直接拒绝掉；做的高大上一些，可以根据一定的用户规则进行拒绝策略。

服务降级

降级甚至关掉后台的某些服务。

特权请求

在多租户或者对用户进行分级时，可以考虑让一些特殊的用户有限处理，其他的可以考虑干掉

延时处理

可以利用队列把请求缓存住。削峰填谷。