从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

李运华 2018-07-07
异地多活方案主要应对系统级的故障,例如,机器宕机、机房故障、网络故障等问题,这些系统级的故障虽然影响很大,但发生概率较小。在实际业务运行过程中,还有另外一种故障影响可能没有系统级那么大,但发生的概率较高,这就是今天我要与你聊的如何应对接口级的故障
接口级故障的典型表现就是系统并没有宕机,网络也没有中断,但业务却出现问题了。例如,业务响应缓慢、大量访问超时、大量访问出现异常(给用户弹出提示“无法连接数据库”),这类问题的主要原因在于系统压力太大、负载太高,导致无法快速处理业务请求,由此引发更多的后续问题。例如,最常见的数据库慢查询将数据库的服务器资源耗尽,导致读写超时,业务读写数据库时要么无法连接数据库、要么超时,最终用户看到的现象就是访问很慢,一会访问抛出异常,一会访问又是正常结果。
导致接口级故障的原因一般有下面几种:
内部原因
程序 bug 导致死循环,某个接口导致数据库慢查询,程序逻辑不完善导致耗尽内存等。
外部原因
黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户,第三方系统大量请求,第三方系统响应缓慢等。
解决接口级故障的核心思想和异地多活基本类似:优先保证核心业务优先保证绝大部分用户
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(36)

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

    作者回复: 分析全面👍👍

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

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

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

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

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

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

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

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

    2018-08-10
    5
  • qpm
    1、在抢购开始前,可以通过降级来保证登陆服务。例如提前半小时限制注册、修改用户信息的服务。
    2、整个流量的洪峰应该在于下单。下单可以同时基于限流和排队两种方案,这个需要大概估计到。譬如说100W人抢购100件商品,可以在整点时对下单操作做99%的限流,把1000K的访问问题改写为10k,10k里面再进行排队。
    3、支付属于第三方调用,使用熔断机制(譬如说下单后保留30分钟的支付的时间,等待支付宝服务恢复)

    未实际开发过实际抢购系统,期望老师和其他同学提供好的方案借鉴学习

    作者回复: 基本思路就是这样的,另外,登录也可以降级

    2018-07-07
    4
  • 孙振超
    登录大体可分为免密登录和非免密登陆(包含登陆密码、人脸登陆、短信登录等),95%左右的都是免密登录,内部的实现相对也比较简单,采用限流方式就可以了;对于非免密登录,内部实现相对会复杂些,并且会有风控策略,因而面对大流量需要同时采取限流和内部降级两种策略了。
    对于抢购,优先采用排队策略,可以避免限流策略下前面的用户因限流导致抢购失败而后面的用户限流通过情况下用户体验不好的情况。
    支付采用熔断策略即可,同时要将对应的错误码进行适当的优化,并提供用户再次进行支付的入口。熔断策略的实现可能会稍微有点复杂,并且需要系统报警+人工确认双重保证,避免网络、机器、电源等情况引起的误触发。

    作者回复: 正确

    2018-09-09
    3
  • Tom
    功能:登录、抢购、支付。

    接口故障应对方法:降级、熔断、限流和排队。

    三个功能是有依赖关系的,登录了才能抢购,抢购了才能支付。因此如果从依赖关系考虑,总体访问量过大无法满足时,降级时优先保留登录,其次是抢购,再其次是支付。但是支付是成交关键,并且访问数量比登录抢购少很多,可以说不是一个数量级,因此我觉得支付优先级是最高的。

    其中只有支付涉及外部调用,因此只需为支付提供熔断方案。

    抢购功能提供排队和限流方案,对于每个参与抢购活动的商品根据商品数量设定队列长度,限流也根据商品数量进行限流。

    支付失败要怎么处理?

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

    支付失败真没什么好办法了,因为这是核心链路的核心功能。

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

    作者回复: 正确👍

    2018-09-27
    2
  • 各个诗坤
    我认为核心需要保证的业务的是抢购,抢购业务可能并发用户较多,对于抢购可以采取排队策略,对参与抢购的用户进行排队。对于登录服务,当发生接口故障的时候,为了保证抢购业务顺利,可以采取降级策略,可以让部分用户登录失败,可以停掉注册等接口,当大量调用支付系统,而支付系统反应慢而影响整个系统的时候,可以对支付系统进行容错处理,可以让用户过段时间再支付。对于熔断的阈值可以根据具体的业务来判断。

    作者回复: 分析正确👍👍

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

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

    2018-07-26
    2
  • 100kg
    老师,我有个双机那节的问题,如果采用了mysql 双主架构,对于库存这样的字段,在并发较高时,如果两个mysql同时 update 了库存(采用乐观锁,库存本身作为版本号),这样会不会导致货物被两个人购买但库存却只减了1呢?该怎么解决呢?求赐教

    作者回复: 会的,库存不能用双主

    2018-07-08
    2
  • 小狮子辛巴

    第一版(不看评论的思考回答)

    假如有100种商品,每个商品1k件。首先设计100个队列。
    对于已经登录的用户
    限定每个队列只能有1w个排队的人,如果超过1w人,就提示人数太大,只能等下次了。

    已经未登录的用户
    如果抢购时间段同时登录人数太多,超过100w, 逐步降级和熔断
    a.可以登录,但不能参与抢购了
    b.暂停登录,拒绝服务 (防止把系统拖垮,影响正常的不抢购的用户)

    第二版(看过评论之后的思考回答)
    1、 忘记了熔断是对外的。老师特意提示了依赖了第三方支付。
    所以上面 逐步降级和熔断 感觉应该是 逐步降级和限流

    假如有100种商品,每个商品1k件。首先设计100个队列。
    对于已经登录的用户
    1、抢购 限定每个队列只能有1w个排队的人,如果超过1w人,就提示人数太大,只能等下次了。
    2、熔断处理, 提示抢购成功的同学,“歇歇再支付,不着急。” 分散支付请求 。
    已经未登录的用户
    如果抢购时间段同时登录人数太多,超过100w, 逐步降级
    a.可以登录,但不能参与抢购了
    b.暂停登录,拒绝服务 (防止把其他系统拖垮,影响正常的不抢购的用户)

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

    2018-11-20
    1
  • 今天
    感谢老师的专栏,写的很专业,学到了很多,物超所值,尤其是一些方法类的东西,受益终生,以前学习过程中的疑问,也从老师这找到了答案。也期待老师的其他专栏。

    作者回复: 没有其它专栏的计划,写个专栏要几年😂

    2018-10-06
    1
  • 衣申人
    整点前降级其他非核心功能,登录采用限流,抢购采用排队加限流,支付对支付宝要有熔断,可加限流。完毕!

    作者回复: 没问题就降级,有点过分了呀,产品经理要打你😂
    另外,支付最好也不要限流,支付限流的话,用户体验很不好,还不如前面限流

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

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

    2018-07-07
    1
  • Geek_88604f
    如果你来设计一个整点限量秒杀系统,包括登录、抢购、支付(依赖支付宝)等功能,你会如何设计接口级的故障应对手段?
            登录是首先要保证的,所以最好不要做限流或排队,因为登录功能非常影响用户的体验。万一出了状况那也只能限流了。
            在用户登录成功发出抢购请求后如果出现后端故障或响应慢则应该考虑针对实际情况做降级或熔断。
            一旦用户抢购成功发起了支付请求则应通过排队来确保支付成功。

    作者回复: 可以看看其它评论

    2019-09-20
  • godtrue
    课后思考及问题
    1:降级——冗余代码或开关控制逻辑,当依赖的基础服务无法提供时,选择提供次一级的服务。
    2:熔断——冗余代码开关逻辑,当依赖的某个外部服务提供的变量值达到某个特定值的时候,走别的分治逻辑
    3:限流——流量超过预期的量,对超过的量进行限制,抛弃或先缓存一下随后处理
    4:排队——也是流量过多,或者需要保留请求的处理次序,使用队列的方式缓存处理信息随后再处理。

    如果我来设计一个整点限量秒杀系统,包括登录、抢购、支付(依赖支付宝)等功能,我会如何设计接口级的故障应对手段?
    登录——我认为需要在前端加上验证码校验就行,防止同一个用户或用一个IP疯狂的登录,至于后端不应该做过多的限制,一个系统连登录都不行,估计会影响比较大。
    抢购——这个是秒杀的关键,这里需要对接口进行限流、排队的控制,防止流量洪峰瞬间将系统拖垮。
    支付——抢购成功后需要支付成功才算秒杀成功,这里又依赖支付宝这个外部服务,经抢购的过滤流量应该会下降不少,不过也要防止支付宝服务不稳定的情况发生,需要做好降级和熔断的业务处理。降级服务,需要安慰一下抢购成功支付失败的客户。
    2019-09-01
  • GeekCoder
    如何应对域名故障?如域名被hold。

    作者回复: 如果是APP,可以用HTTP-DNS,如果是网页,基本没办法

    2019-07-05
  • 梁中华
    为啥没提供一些工具组建供参考

    作者回复: 不同语言不同行业都不同,JAVA推荐spring全家桶

    2019-05-10
收起评论
36
返回
顶部