31 | 如何应对接口级的故障？

1.对于用户服务，在抢购期间可以准备降级策略，压力过大时保证用户登录的可用，注册和修改信息可以做降级处理 2.抢购下单涉及到订单，库存，和商品查询。可通过请求排队来限流，超出库存的请求直接返回。 为了应对库存和商品服务可能发生的故障，可以提前对商品数据和库存数据做缓存，如果对端服务故障，本地也可以提供服务 3.支付依赖第三方系统，合理设置熔断策略，如支付平均时长超过限制可提示用户稍晚做支付

1.抢购页面最大程度静态化，一般用户开始前会尝试刷新页面，查询压力要比下单压力大很多 2.抢购页面要求登陆后访问，一般人不会抢购开始那一刻才进来，错开登陆压力 3.活动未开始，不允许点击抢购按钮。对请求做轻量分析，对于请求过频繁或者可疑ua等做拉黑，为防误杀要求输验证码 4.抢购下单接口采用排队+限流，降低压力的同时保证公平性，如抢购1000件，只放2000人进来，其他返回排队人数过多。进来的请求全部入列，固定数量的队列消费者控制订单生成速率以及走到支付流程的速率。支付是下单流程核心功能，降级不应该降级掉。队列做削峰，保证支付系统不会压力过大。 请指正～

我发现了,系列文章越到后面,人越少.还好我坚持看到了这里...

1.登录接口在流量特别大的时候，可以适当降级，较少参与人数，另外一点是登录一般有有效期（尤其对于web客户端），可以适当延长登录有效期。2.抢购接口采用队列方式，无法支撑时，也可以适当限流。另外一点，秒杀一般还会有一个秒杀结果查询的接口，也可以降级或者减小请求频次。3.支付接口，一般第三方支付对接入方有流量限制，可以提前申请扩大限制，同时做好降级准备。

整点限量抢购核心业务应该是登录和抢购，抢购完了放入购物车不一定马上支付，所以在系统负载较高的时候可以让支付接口做降级处理，过了整点再恢复。抢购接口一般采取商品对应一个抢购队列，队列到上限之后拒绝流量进来，系统根据自身负载情况去消息队列进行流量的拉取，大致思路如上所述，还有什么遗漏还请老师指教

老师你好，关于排队方式请教个问题： 比如用户从pc发一个请求过来，我们将这个请求放到队列，这个时候就直接返回客户端，客户端定时轮训排队状况，还是说是其它处理方案呢？

功能：登录、抢购、支付。 接口故障应对方法：降级、熔断、限流和排队。 三个功能是有依赖关系的，登录了才能抢购，抢购了才能支付。因此如果从依赖关系考虑，总体访问量过大无法满足时，降级时优先保留登录，其次是抢购，再其次是支付。但是支付是成交关键，并且访问数量比登录抢购少很多，可以说不是一个数量级，因此我觉得支付优先级是最高的。 其中只有支付涉及外部调用，因此只需为支付提供熔断方案。 抢购功能提供排队和限流方案，对于每个参与抢购活动的商品根据商品数量设定队列长度，限流也根据商品数量进行限流。 支付失败要怎么处理？

第一版（不看评论的思考回答） 假如有100种商品，每个商品1k件。首先设计100个队列。 对于已经登录的用户 限定每个队列只能有1w个排队的人，如果超过1w人，就提示人数太大，只能等下次了。 已经未登录的用户 如果抢购时间段同时登录人数太多，超过100w, 逐步降级和熔断 a.可以登录，但不能参与抢购了 b.暂停登录，拒绝服务 （防止把系统拖垮，影响正常的不抢购的用户） 第二版（看过评论之后的思考回答） 1、 忘记了熔断是对外的。老师特意提示了依赖了第三方支付。 所以上面 逐步降级和熔断 感觉应该是 逐步降级和限流 假如有100种商品，每个商品1k件。首先设计100个队列。 对于已经登录的用户 1、抢购 限定每个队列只能有1w个排队的人，如果超过1w人，就提示人数太大，只能等下次了。 2、熔断处理， 提示抢购成功的同学，“歇歇再支付，不着急。” 分散支付请求 。 已经未登录的用户 如果抢购时间段同时登录人数太多，超过100w, 逐步降级 a.可以登录，但不能参与抢购了 b.暂停登录，拒绝服务 （防止把其他系统拖垮，影响正常的不抢购的用户）

访问的流量在每个环节可能逐步递减（登陆例外） 1、引导部分用户提前登陆； 2、秒杀价系统独立部署（感觉和其他系统部署在一起才需要降级）； 3、抢购使用排队方式。有界队列，队列大小可以预估较大长度，队列外的拒绝； 4、（如果要求以支付成功为准）通过队列和熔断。 （如果以下单成功为准）使用熔断。提醒稍后再付

“每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。”我之前也思考过类似于淘宝秒杀或12306这种高并发系统，应该不会所以资源在一个队列里排队，这样整个系统并发度无法水平伸缩，那么请问老师一个技术细节问题，每个商品一个队列这个有啥推荐的实现方案吗？