高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
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:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
高并发系统设计40问
登录|注册

01 | 高并发系统:它的通用设计方法是什么?

唐扬 2019-09-18
我们知道,高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。
来做个简单的比喻吧。
从古至今,长江和黄河流域水患不断,远古时期,大禹曾拓宽河道,清除淤沙让流水更加顺畅;都江堰作为史上最成功的的治水案例之一,用引流将岷江之水分流到多个支流中,以分担水流压力;三门峡和葛洲坝通过建造水库将水引入水库先存储起来,然后再想办法把水库中的水缓缓地排出去,以此提高下游的抗洪能力。
而我们在应对高并发大流量时也会采用类似“抵御洪水”的方案,归纳起来共有三种方法。
Scale-out(横向扩展):分而治之是一种常见的高并发系统设计方法,采用分布式部署的方式把流量分流开,让每个服务器都承担一部分并发和流量。
缓存:使用缓存来提高系统的性能,就好比用“拓宽河道”的方式抵抗高并发大流量的冲击。
异步:在某些场景下,未处理完成之前,我们可以让请求先返回,在数据准备好之后再通知请求方,这样可以在单位时间内处理更多的请求。
简单介绍了这三种方法之后,我再详细地带你了解一下,这样当你在设计高并发系统时就可以有考虑的方向了。当然了,这三种方法会细化出更多的内容,我会在后面的课程中深入讲解。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(72)

  • 老男孩
    martin fowler好像曾经说过,能使用单体解决的问题,就不要采用分布式。不能为了技术而技术,采用分布式固然可以分流用户请求,提高系统的响应能力,但同样也带来了复杂性。软件开发最终的目的是商业利益。非常赞成老师的观点,罗马城不是一天就建立起来的。架构的工作应该是阶段性,解决阶段性系统的复杂性。如果单体跑的很好,或者通过scale up方式在成本可控的情况能解决就不要想着诗和远方,因为系统内部的进程间调用,肯定比不同物理机的进程之间调用要快。

    作者回复: 说的真好!

    2019-09-18
    1
    58
  • 镜子
    之前做的创业项目也是遇到盲目优化的问题,系统最核心的撮合结算服务,刚开始只能100次每秒,后来为了优化到百万级,花了大量时间研究各种方案,做了大量的性能测试,耽误了很长时间推向市场,结果最终优化到了不到一万tps,但后面真正上线的结果可能不到也就100tps,所以真正的需求是市场需求,不是一开始就冲着最牛逼的方案搞,线上的需求远比一开始的预想复杂,没足够的资源和动力,绝对不要折腾,不过时刻准备好可能会出现的瓶颈是必要的,免得半夜宕机,慌得一比
    2019-09-18
    1
    12
  • 吕宗胜ZJU
    高并发除了横向扩容,缓存和异步化,系统还需要做好保护,比如限流降级,过载保护。甚至高并发的问题更是一个系统性问题,从前端到服务端,从产品设计上都要考虑进来。不过这块就比较业务化了,不是常规的操作
    2019-09-18
    2
    12
  • 逍遥法外
    架构设计的过程中要识别每个阶段的复杂度,有针对的做架构设计。避免过度设计带来的成本上升。这个原则和李运华老师的架构课讲的架构设计的原则不谋而合。😄
    2019-09-18
    10
  • 三年过后
    老师讲得很好!不过,还是觉得偏理论较多。例如,讲到踩过很多坑,这些坑没有一些案例说明和后来的解决问题方案。比如,之前负责的支付系统项目,在流量不是很大的情况下,就引入了zk集群(3台)zk集群所在的线上服务,存在一台宕机,整个线上支付都不可用。后面解决:只好切回单体服务

    作者回复: 后面课程会有一些关键知识点的案例介绍的

    2019-09-18
    8
    9
  • Luciano李鑫
    代部落伙伴问个问题:关于秒杀这种场景我想的是用redis的list不就完全可以实现吗。活动开始前,先把要抢的N个商品push到list中。活动开始后,每来一个请求就从list中pop一个商品出去,当list为空后直接返回“已抢光”的响应,由于可秒杀的商品数量并不多,能通过的请求也可以采用同步的方式进行,这样不是既简单又快速。可是我搜了一下网上的方案,都特别的复杂,请问这种方式有什么问题吗?

    作者回复: 这个商品应该是放在单一的redis节点里面的吧,放在多个节点里面不好维护一致性。那么如果在流量或者带宽方面超过单个节点的限制咋办?是否要考虑动态和静态数据的隔离?是否要考虑降低redis的写流量峰值?所以流量大了,自然方案就复杂了~

    2019-09-19
    12
    8
  • 黑暗浪子
    现阶段大多数公司其实都没机会碰到高并发。很多时候我们学习它,只是为了将来有一天要用到时候不会一脸懵。继续学习~期待以后的精彩分享
    2019-09-19
    7
  • 蓝魔丶
    我们公司一开始就采用了微服务架构方案,但在实施过程中却缺乏架构演进和优化过程,在支撑业务的同时也造成了很多运维和技术痛点
    2019-09-18
    7
  • 1.技术在不断演进,演进的目的和内驱动力是解决当前系统存在的问题,过早过度设计大多只会延误系统的发展。一切都以实际情况和需要出发,一步步优化,一步步演进,个人能力提升也是同样的道理。
    2.高并发系统设计通用方法:水平拓展,缓存,异步。这只是指导思想,如何更巧妙的运用才是最具魅力的。

    作者回复: 说的真好!

    2019-09-18
    6
  • 马留
    老师,你把“缓存”比喻成“拓宽河道”,个人觉得是不妥当的,应是建水库更好些。拓宽河道比较类似Scale-out

    作者回复: scale-out可以理解为引流和分流;缓存的作用是提速,拓宽河道的作用也是提速,所以有一些的关联

    2019-09-18
    3
    4
  • 兔2🐰🍃
    目前的芯片技术已经到达5nm级别了,最近台积电生产的高通骁龙875,使用的是5nm工艺制造,晶体管密度提升到1.713亿/mm²(这个数据看到时也惊讶到了),比7nm提升70%左右,大概2021年的手机上会普遍起来。

    作者回复: 优秀!这个我确实没有了解很多,感谢提醒:)

    2019-09-18
    1
    4
  • MYG
    讲得真好!小建议,对于一些关键的术语可不可以像我们讲scale-out一样,同时使用中文和英文呢?比如cache,async,这样可以方便将来同时查阅中英文文献。

    作者回复: 好嘞,以后我会注意的:)

    2019-09-19
    3
  • 业余草
    微服务不是架构演变的终点!

    https://mp.weixin.qq.com/s/TAHtAreMkxjWLfW1jSP88w

    作者回复: 架构演变是没有终点的:)

    2019-09-18
    5
    3
  • 行者
    谢谢老师分享。
    系统设计的时候,不能一心求大,而是应该有多少人做多少饭,避免不必要的浪费。
    拿做饭举例,假设现在有1口锅,可以一次给10人做饭。
    突然有一天要给100人做饭,
    scale-out,扩展到10口锅来做饭;
    缓存,1口锅在人来之前做10次;
    异步,人来了,让大家先等着,做饭给大家端过去,不要在都在锅边等着。
    2019-09-26
    4
    2
  • yuan
    老师,消息队列用到缓存,之前没有听说过这个,请问哪种消息队列用到缓存?

    作者回复: 内部实现会用到缓存的思想,Kafka会用到pagecache

    2019-09-24
    2
  • 雾里看花
    为什么说缓存是拓宽河道呢?

    作者回复: 拓宽河道可以认为是加快水流速度,和缓存加速的思想差不多一致

    2019-09-20
    2
  • 由莫
    把缓存比喻成拓宽河道不合理。从另外的角度来看,拓宽河道就是增加流量的带宽。这跟缓存放在一起说感觉让人对缓存有误解。

    作者回复: 当时考虑的是拓宽河道是让水流更快,和缓存思想比较接近

    2019-09-18
    2
    2
  • 吃饭饭
    我更喜欢从成本和用户量的角度去考虑架构的实现方案,细想一下,正好迎合了老师的循序渐进。
    2019-09-18
    2
  • 一步
    Scale-out 横向扩展
    Scale-up 纵向扩展
    2019-09-18
    2
  • 鞠小军
    总结:高并发设计三种思路
    1、横向扩展
    2、缓存
    3、异步

    首先,不能为了设计而设计,不要过度设计。单机满足业务需求就不要分布式,架构不能盲目,架构一定是逐步演进的,而且是随着业务的需求逐步进行的。

    三种思路理解要宽泛。比如横向扩展可以是集群,可以是主从分离,也可以是分库分表等等。

    缓存呢其实无处不在,比如CPU的一级缓存、二级缓存、三级缓存,操作系统缓存(如windows的page.sys文件),mybatis的一级缓存,二级缓存等等。

    异步就是解藕操作,比如将订单成交的消息我需要保证准确性而不是实时性,因此就先放入消息队列中,消息被消费的时候在进行业务的处理,这样就可以提高并发请数量

    作者回复: 👍

    2019-11-07
    1
收起评论
72
返回
顶部