从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

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

关键资源:连接数、文件句柄、线程数、请求队列
限制时间量
限制总量
令牌桶算法
漏桶算法
滑动时间窗
固定时间窗
独立排队系统
目的:让用户等待一段时间
基于资源限流
基于请求限流
目的:从用户访问压力角度应对故障
实现关键点:统一的API调用层、阈值的设计
目的:应对依赖的外部系统故障
独立降级系统
系统后门降级
限流算法:时间窗算法、桶算法
接口级故障应对方法:降级、熔断、限流、排队
桶算法
时间窗算法
排队
限流
熔断
降级
优先保证核心业务和绝大部分用户
原因:系统压力过大,负载过高
系统没有宕机,但业务出现问题
总结
限流算法
应对方法
解决接口级故障的核心思想
接口级故障的表现
如何应对接口级的故障?

该思维导图由 AI 生成,仅供参考

你好,我是华仔。
前几讲我介绍了异地多活方案。它主要用来应对系统级的故障,例如机器宕机、机房故障和网络故障等问题。这些系统级的故障虽然影响很大,但发生概率较小。在实际业务运行过程中,还有另外一种故障影响可能没有那么大,但发生的概率较高,这就是今天我要跟你聊的接口级的故障。
接口级故障的典型表现就是,系统并没有宕机、网络也没有中断,但业务却出现问题了,例如业务响应缓慢、大量访问超时和大量访问出现异常(给用户弹出提示“无法连接数据库”)。
这类问题的主要原因在于系统压力太大、负载太高,导致无法快速处理业务请求,由此引发更多的后续问题。最常见的情况就是,数据库慢查询将数据库的服务器资源耗尽,导致读写超时,业务读写数据库时要么无法连接数据库、要么超时,最终用户看到的现象就是访问很慢,一会儿访问抛出异常,一会儿访问又是正常结果。
如果进一步探究,导致接口级故障的原因可以分为两大类:
内部原因:包括程序 bug 导致死循环,某个接口导致数据库慢查询,程序逻辑不完善导致耗尽内存等。
外部原因:包括黑客攻击,促销或者抢购引入了超出平时几倍甚至几十倍的用户,第三方系统大量请求,第三方系统响应缓慢等。
解决接口级故障的核心思想和异地多活基本类似,都是优先保证核心业务优先保证绝大部分用户。常见的应对方法有四种,降级、熔断、限流和排队,下面我会一一讲解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

接口级故障的原因和解决方法是本文的重点内容。文章深入介绍了限流算法在解决接口级故障中的应用,着重讨论了时间窗算法和桶算法两大类限流算法的实现原理、优缺点及适用场景。固定时间窗算法存在临界点问题,而滑动时间窗算法能更好地解决此问题。漏桶算法适用于瞬时高并发流量的场景,而令牌桶算法适用于控制访问速度的场景。此外,文章还介绍了排队作为限流的一种变种,以及排队系统的架构和基本实现。通过阅读本文,读者可以深入了解接口级故障的应对方法,以及不同限流算法的原理和适用场景,为读者提供了实用的技术指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(58)

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

    作者回复: 分析全面👍👍

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

    作者回复: 分析的很好,支付如果依赖第三方的话,需要考虑熔断,然后做补偿或者容错措施,例如提示用户10分钟后再来支付

    2018-07-08
    3
    51
  • 张浩
    我发现了,系列文章越到后面,人越少.还好我坚持看到了这里...

    作者回复: 😄😄被你发现了,一定要坚持

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

    作者回复: 分析更好,支付接口依赖第三方应该是熔断,然后做好容错措施,例如提示用户10分钟后来支付

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

    作者回复: 一般不建议对支付做降级,用户体验很不好,还不如登录和抢购阶段限流,这是有心理学理论支撑的,用户没抢到前,如果抢不到他会认为自己运气不好,但如果用户抢到了没法支付,他会觉得自己损失了,会触发“损失厌恶”心理😄

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

    作者回复: 常见的有:1. 轮询,2. Long polling,3. HTTP/2推送

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

    作者回复: 假如降级时优先保证登录,但是用户登录进来后发现抢购不了,其实体验也不好,而且已经抢购了的用户可能无法支付,这样体验更不好,甚至会引起投诉,因此抢购类降级是优先降登录会好些,保留抢购和支付,保证进来的用户能够完成业务流程。 支付失败真没什么好办法了,因为这是核心链路的核心功能。

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

    作者回复: 认真思考,点赞👍

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

    作者回复: 正确👍

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

    作者回复: 用kafka,用商品id做队列名称就可以了

    2018-07-26
    5
收起评论
显示
设置
留言
58
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部