异地多活方案主要应对系统级的故障，例如，机器宕机、机房故障、网络故障等问题，这些系统级的故障虽然影响很大，但发生概率较小。在实际业务运行过程中，还有另外一种故障影响可能没有系统级那么大，但发生的概率较高，这就是今天我要与你聊的如何应对接口级的故障。
接口级故障的典型表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了。例如，业务响应缓慢、大量访问超时、大量访问出现异常（给用户弹出提示“无法连接数据库”），这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。例如，最常见的数据库慢查询将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无法连接数据库、要么超时，最终用户看到的现象就是访问很慢，一会访问抛出异常，一会访问又是正常结果。
导致接口级故障的原因一般有下面几种：
- 内部原因
程序 bug 导致死循环，某个接口导致数据库慢查询，程序逻辑不完善导致耗尽内存等。
- 外部原因
黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户，第三方系统大量请求，第三方系统响应缓慢等。
解决接口级故障的核心思想和异地多活基本类似：优先保证核心业务和优先保证绝大部分用户。
降级
降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。例如，论坛可以降级为只能看帖子，不能发帖子；也可以降级为只能看帖子和评论，不能发评论；而 App 的日志上传接口，可以完全停掉一段时间，这段时间内 App 都不能上传日志。
降级的核心思想就是丢车保帅，优先保证核心业务。例如，对于论坛来说，90% 的流量是看帖子，那我们就优先保证看帖的功能；对于一个 App 来说，日志上传接口只是一个辅助的功能，故障时完全可以停掉。
常见的实现降级的方式有：
- 系统后门降级
简单来说，就是系统预留了后门用于降级操作。例如，系统提供一个降级 URL，当访问这个 URL 时，就相当于执行降级指令，具体的降级指令通过 URL 的参数传入即可。这种方案有一定的安全隐患，所以也会在 URL 中加入密码这类安全措施。
系统后门降级的方式实现成本低，但主要缺点是如果服务器数量多，需要一台一台去操作，效率比较低，这在故障处理争分夺秒的场景下是比较浪费时间的。
- 独立降级系统
为了解决系统后门降级方式的缺点，将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。其基本架构如下：
熔断
熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但其实内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。
假设一个这样的场景：A 服务的 X 功能依赖 B 服务的某个接口，当 B 服务的接口响应很慢的时候，A 服务的 X 功能响应肯定也会被拖慢，进一步导致 A 服务的线程都被卡在 X 功能处理上，此时 A 服务的其他功能都会被卡住或者响应非常慢。这时就需要熔断机制了，即：A 服务不再请求 B 服务的这个接口，A 服务内部只要发现是请求 B 服务的这个接口就立即返回错误，从而避免 A 服务整个被拖慢甚至拖死。
熔断机制实现的关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。
熔断机制实现的另外一个关键是阈值的设计，例如 1 分钟内 30% 的请求响应时间超过 1 秒就熔断，这个策略中的“1 分钟”“30%”“1 秒”都对最终的熔断效果有影响。实践中一般都是先根据分析确定阈值，然后上线观察效果，再进行调优。
限流
降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。
虽然“丢弃”这个词听起来让人不太舒服，但保证一部分请求能够正常响应，总比全部请求都不能响应要好得多。
限流一般都是系统内实现的，常见的限流方式可以分为两类：基于请求限流和基于资源限流。
- 基于请求限流
基于请求限流指从外部访问的请求角度考虑限流，常见的方式有：限制总量、限制时间量。
限制总量的方式是限制某个指标的累积上限，常见的是限制当前系统服务的用户总量，例如某个直播间限制总用户数上限为 100 万，超过 100 万后新的用户无法进入；某个抢购活动商品数量只有 100 个，限制参与抢购的用户上限为 1 万个，1 万以后的用户直接拒绝。限制时间量指限制一段时间内某个指标的上限，例如，1 分钟内只允许 10000 个用户访问，每秒请求峰值最高为 10 万。
无论是限制总量还是限制时间量，共同的特点都是实现简单，但在实践中面临的主要问题是比较难以找到合适的阈值，例如系统设定了 1 分钟 10000 个用户，但实际上 6000 个用户的时候系统就扛不住了；也可能达到 1 分钟 10000 用户后，其实系统压力还不大，但此时已经开始丢弃用户访问了。
即使找到了合适的阈值，基于请求限流还面临硬件相关的问题。例如一台 32 核的机器和 64 核的机器处理能力差别很大，阈值是不同的，可能有的技术人员以为简单根据硬件指标进行数学运算就可以得出来，实际上这样是不可行的，64 核的机器比 32 核的机器，业务处理性能并不是 2 倍的关系，可能是 1.5 倍，甚至可能是 1.1 倍。
为了找到合理的阈值，通常情况下可以采用性能压测来确定阈值，但性能压测也存在覆盖场景有限的问题，可能出现某个性能压测没有覆盖的功能导致系统压力很大；另外一种方式是逐步优化，即：先设定一个阈值然后上线观察运行情况，发现不合理就调整阈值。
基于上述的分析，根据阈值来限制访问量的方式更多的适应于业务功能比较简单的系统，例如负载均衡系统、网关系统、抢购系统等。
- 基于资源限流
基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，即：找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列等。
例如，采用 Netty 来实现服务器，每个进来的请求都先放入一个队列，业务线程再从队列读取请求进行处理，队列长度最大值为 10000，队列满了就拒绝后面的请求；也可以根据 CPU 的负载或者占用率进行限流，当 CPU 的占用率超过 80% 的时候就开始拒绝新的请求。
基于资源限流相比基于请求限流能够更加有效地反映当前系统的压力，但实践中设计也面临两个主要的难点：如何确定关键资源，如何确定关键资源的阈值。通常情况下，这也是一个逐步调优的过程，即：设计的时候先根据推断选择某个关键资源和阈值，然后测试验证，再上线观察，如果发现不合理，再进行优化。
排队
排队实际上是限流的一个变种，限流是直接拒绝用户，排队是让用户等待一段时间，全世界最有名的排队当属 12306 网站排队了。排队虽然没有直接拒绝用户，但用户等了很长时间后进入系统，体验并不一定比限流好。
由于排队需要临时缓存大量的业务请求，单个系统内部无法缓存这么多数据，一般情况下，排队需要用独立的系统去实现，例如使用 Kafka 这类消息队列来缓存用户请求。
下面是 1 号店的“双 11”秒杀排队系统架构
其基本实现摘录如下：
【排队模块】
负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。
【调度模块】
负责排队模块到服务模块的动态调度，不断检查服务模块，一旦处理能力有空闲，就从排队队列头上把用户访问请求调入服务模块，并负责向服务模块分发请求。这里调度模块扮演一个中介的角色，但不只是传递请求而已，它还担负着调节系统处理能力的重任。我们可以根据服务模块的实际处理能力，动态调节向排队系统拉取请求的速度。
【服务模块】
负责调用真正业务来处理服务，并返回处理结果，调用排队模块的接口回写业务处理结果。
小结
今天我为你讲了接口级故障的四种应对方法，分别是降级、熔断、限流和排队，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧，如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等功能，你会如何设计接口级的故障应对手段？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）
版权归极客邦科技所有，未经许可不得转载
精选留言
2.抢购下单涉及到订单，库存，和商品查询。可通过请求排队来限流，超出库存的请求直接返回。
为了应对库存和商品服务可能发生的故障，可以提前对商品数据和库存数据做缓存，如果对端服务故障，本地也可以提供服务
3.支付依赖第三方系统，合理设置熔断策略，如支付平均时长超过限制可提示用户稍晚做支付
2.抢购页面要求登陆后访问，一般人不会抢购开始那一刻才进来，错开登陆压力
3.活动未开始，不允许点击抢购按钮。对请求做轻量分析，对于请求过频繁或者可疑ua等做拉黑，为防误杀要求输验证码
4.抢购下单接口采用排队+限流，降低压力的同时保证公平性，如抢购1000件，只放2000人进来，其他返回排队人数过多。进来的请求全部入列，固定数量的队列消费者控制订单生成速率以及走到支付流程的速率。支付是下单流程核心功能，降级不应该降级掉。队列做削峰，保证支付系统不会压力过大。
请指正～
接口故障应对方法：降级、熔断、限流和排队。
三个功能是有依赖关系的，登录了才能抢购，抢购了才能支付。因此如果从依赖关系考虑，总体访问量过大无法满足时，降级时优先保留登录，其次是抢购，再其次是支付。但是支付是成交关键，并且访问数量比登录抢购少很多，可以说不是一个数量级，因此我觉得支付优先级是最高的。
其中只有支付涉及外部调用，因此只需为支付提供熔断方案。
抢购功能提供排队和限流方案，对于每个参与抢购活动的商品根据商品数量设定队列长度，限流也根据商品数量进行限流。
支付失败要怎么处理？
2、整个流量的洪峰应该在于下单。下单可以同时基于限流和排队两种方案，这个需要大概估计到。譬如说100W人抢购100件商品，可以在整点时对下单操作做99%的限流，把1000K的访问问题改写为10k，10k里面再进行排队。
3、支付属于第三方调用，使用熔断机制（譬如说下单后保留30分钟的支付的时间，等待支付宝服务恢复）
未实际开发过实际抢购系统，期望老师和其他同学提供好的方案借鉴学习
1、引导部分用户提前登陆；
2、秒杀价系统独立部署（感觉和其他系统部署在一起才需要降级）；
3、抢购使用排队方式。有界队列，队列大小可以预估较大长度，队列外的拒绝；
4、（如果要求以支付成功为准）通过队列和熔断。
（如果以下单成功为准）使用熔断。提醒稍后再付
对于抢购，优先采用排队策略，可以避免限流策略下前面的用户因限流导致抢购失败而后面的用户限流通过情况下用户体验不好的情况。
支付采用熔断策略即可，同时要将对应的错误码进行适当的优化，并提供用户再次进行支付的入口。熔断策略的实现可能会稍微有点复杂，并且需要系统报警+人工确认双重保证，避免网络、机器、电源等情况引起的误触发。
支付功能调用支付宝服务，可以使用熔断和限流。
由于有多种抢购产品，每个产品的抢购规则可能不太一样，可以定制开发一个通用抢购服务，此服务具有类似限流功能。或者可以使用文中消息队列方式，达到类似限流功能。
比如用户从pc发一个请求过来，我们将这个请求放到队列，这个时候就直接返回客户端，客户端定时轮训排队状况，还是说是其它处理方案呢？
抢购分为多步进行，首先有验证吗！可以减小并发的秒杀数；抢购还有队列，比如商品最大1000，队列限制在1200，最大可接受1200请求，其他直接提示秒杀结束
秒杀到的商品，需要支付，可使用排队进行支付
其次对于登录，可以采用排队机制，合理限制参加抢购的人数。
最后，如果调用支付接口拖慢了系统，可以采用熔断机制，从而保证系统的可用性。
登录可以使用降级或者排队策略（但我可能觉得不一定会使用，因为实际场景一般是用户都提前登录好了）；
抢购可以使用排队策略，再加上资源限流方式，主要基于cpu和内存；
支付可以使用排队策略，加上限流策略，如果支付宝响应慢，可以降低通过的个数；如果中途有人支付失败，需重新发起支付；如果有人放弃支付，可调用刚才排队队列中的相应请求再去支付，直到商品被抢购完成；
当然还有高性能➡️高可用方面的问题
以上是我的拙见……
如果不允许，切涉及一些固有系统逻辑，就得用到本篇讲到的方法了，登录，抢购，支付都属核心，
1. 这里能降级的额是其他外围功能，
2. 抢购阶段，队列蓄洪客户请求，限流变种
3. 支付，防止由于第三方依赖系统拖垮，做好熔断处理