高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9308 人已学习
课程目录
已更新 42 讲 / 共 45 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (7讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
35 | 流量控制:高并发系统中我们如何操纵流量?
36 | 面试现场第三期:你要如何准备一场技术面试呢?
实战篇 (2讲)
37 | 计数系统设计(一):面对海量数据的计数器要如何做?
38 | 计数系统设计(二):50万QPS下如何设计未读数系统?
高并发系统设计40问
登录|注册

34 | 降级熔断:如何屏蔽非核心系统故障的影响?

唐扬 2019-12-11
你好,我是唐扬。
到目前为止,你的电商系统已经搭建了完善的服务端和客户端监控系统,并且完成了全链路压测。现在呢,你们已经发现和解决了垂直电商系统中很多的性能问题和隐患。但是千算万算,还是出现了纰漏。
本来,你们对于应对“双十一”的考验信心满满,但因为欠缺了一些面对巨大流量的经验,在促销过程中出现了几次短暂的服务不可用,这给部分用户造成了不好的使用体验。事后,你们进行了细致的复盘,追查出现故障的根本原因,你发现,原因主要可以归结为两大类。
第一类原因是由于依赖的资源或者服务不可用,最终导致整体服务宕机。举例来说,在你的电商系统中就可能由于数据库访问缓慢,导致整体服务不可用。
另一类原因是你们乐观地预估了可能到来的流量,当有超过系统承载能力的流量到来时,系统不堪重负,从而出现拒绝服务的情况。
那么,你要如何避免再次出现这两类问题呢?我建议你采取降级、熔断以及限流的方案。限流是解决第二类问题的主要思路(下一节课,我会着重讲解)。今天这节课,我主要讲一下解决第一类问题的思路:降级和熔断。
不过在此之前,我先带你了解一下这个问题为何存在,因为你只有弄清楚出现故障的原理,才能更好地理解熔断降级带来的好处。

雪崩是如何发生的

取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 阿卡牛
    不怕你说不行,就怕你不吭声

    作者回复: 很形象,^_^

    2019-12-13
    4
  • 魏春河
    看着熔断状态变更示意图有问题,状态变化和箭头提示对应有错误
    2019-12-11
    1
  • tt
    嗯,新功能上线时通过开关来实现快速的回滚,即从高版本回滚到低版本也是一种降级。

    这样有选择的降级就和蓝绿发布连接在一起了
    2019-12-11
    1
  • 电光火石
    请问,如果核心业务,比如说双十一的时候,支付场景下,银行跟不上这么大的流量,那这个时候熔断和降级其实都不合适,应该怎么做,谢谢了!

    作者回复: 应该是限流吧。
    另外支付调用银行的接口可以是异步的,然后等待银行的回调,这样就可以把支付请求放入队列,用户的感知是支付成功有些延迟

    2019-12-17
  • 星空123
    dubbo的监控中心也有降级

    作者回复: 是框架提供的降级策略

    2019-12-14
  • 蓝魔丶
    请教老师一个问题,熔断和开关降级都是有损的处理方式,文中提到是针对非核心业务,但是如果核心业务也遇到两类问题的困扰的时候,需要怎么处理?不能采用熔断和开关降级这种方式吗?如果采用后面讲到限流降级可以保证核心业务的可用性,但是还是感觉是有损的,毕竟可能会丢弃部分请求,或者返回错误,所以针对核心业务有什么更好的方式处理吗?尽量对核心业务的损耗更低

    作者回复: 可以使用限流,也可以设置合适的超时时间,还可以扩容

    2019-12-11
收起评论
6
返回
顶部