当我们的系统的访问量突然剧增，大量的请求涌入过来，最典型的就是秒杀业务了，我们可能会知道会有一波高峰，这时候该如何处理？
而且现在很多情况我们还需要调用第三方接口例如支付等，因此我们还得考虑如果第三方那边出问题了，返回异常的慢，我们系统该如何处理。
常见的处理方式有三种：降级、熔断、限流。
降级
降级也就是服务降级，当我们的服务器压力剧增为了保证核心功能的可用性 ，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。 就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。
一般而言都会建立一个独立的降级系统，可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的，例如接口超时降级、失败重试多次降级等。具体失败几次，超时设置多久，由你们的业务等其他因素决定。开个小会，定个值，扔线上去看看情况。根据情况再调优。
熔断
降级一般而言指的是我们自身的系统出现了故障而降级。而熔断一般是指依赖的外部接口出现故障的情况断绝和外部接口的关系。
例如你的A服务里面的一个功能依赖B服务，这时候B服务出问题了，返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能，因此我们这时候就需要熔断！即当发现A要调用这B时就直接返回错误(或者返回其他默认值啊啥的)，就不去请求B了。我这还是举了两个服务的调用，有些那真的是一环扣一环，出问题不熔断，那真的是会雪崩。
当然也有人认为熔断不就是降级的一种的，我觉得你非要说熔断也属于一种降级我也没法反驳，但是它们本质上的突出点和想表达的意思还是有一些不同的。
那什么时候熔断合适呢？也就是到达哪个阈值进行熔断，5分钟内50%的请求都超过1秒？还是啥？参考降级。
限流
上面说的两个算是请求过来我们都受理了，这个限流就更狠了，直接跟请求说对不起再见！也就是系统规定了多少承受能力，只允许这么些请求能过来，其他的请求就说再见了。
一般限制的指标有：请求总量或某段时间内请求总量。
请求总量：比如秒杀的，秒杀100份产品，我就放5000名进来，超过的直接拒绝请求了。
某段时间内请求总量：比如规定了每秒请求的峰值是1W，这一秒内多的请求直接拒绝了。咱们下一秒再见。
