高并发系统设计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问
登录|注册

05 | 系统设计目标(三):如何让系统易于扩展?

唐扬 2019-09-27
从架构设计上来说,高可扩展性是一个设计的指标,它表示可以通过增加机器的方式来线性提高系统的处理能力,从而承担更高的流量和并发。
你可能会问:“在架构设计之初,为什么不预先考虑好使用多少台机器,支持现有的并发呢?”这个问题我在“03 | 系统设计目标(一):如何提升系统性能?”一课中提到过,答案是峰值的流量不可控。
一般来说,基于成本考虑,在业务平稳期,我们会预留 30%~50% 的冗余以应对运营活动或者推广可能带来的峰值流量,但是当有一个突发事件发生时,流量可能瞬间提升到 2~3 倍甚至更高,我们还是以微博为例。
鹿晗和关晓彤互圈公布恋情,大家会到两个人的微博下面,或围观,或互动,微博的流量短时间内增长迅速,微博信息流也短暂出现无法刷出新的消息的情况。
那我们要如何应对突发的流量呢?架构的改造已经来不及了,最快的方式就是堆机器。不过我们需要保证,扩容了三倍的机器之后,相应的我们的系统也能支撑三倍的流量。有的人可能会产生疑问:“这不是显而易见的吗?很简单啊。”真的是这样吗?我们来看看做这件事儿难在哪儿。

为什么提升扩展性会很复杂

在上一讲中,我提到可以在单机系统中通过增加处理核心的方式,来增加系统的并行处理能力,但这个方式并不总生效。因为当并行的任务数较多时,系统会因为争抢资源而达到性能上的拐点,系统处理能力不升反降。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(33)

  • _CountingStars
    memcached 官方没有提供集群特性,一般第三方会使用一致性哈希算法来进行负载均衡实现集群扩展。
    redis 官方的集群选择把数据根据key来哈希分配到固定数量的 slot 上,然后把 slot 再分配到具体的redis实例上来实现集群,当需要扩展时,只需要把 slot 分配一些到新加入的 redis 实例即可。这种多加一层来实现集群扩展的方式,类似于我们数据库分表时使用的索引表。

    作者回复: 👍👍👍👍

    2019-09-27
    2
    11
  • coffee
    关系型数据库是强schema约束,并且支持事务,所以扩展性相对较差。
    NOSQL一般都不是强schema约束的,所以可扩展性比关系型数据库要好。

    作者回复: 不只是schema free,还在于支持auto sharding

    2019-09-27
    10
  • A.Windy
    这不就是微服务嘛😄

    作者回复: 是的哦

    2019-09-29
    6
  • 岁寒
    很很有感触,最近在做微服务拆分,面试过许多人,他们做拆分,是按照接口拆分,并不会按业务拆分,在我自己做的时候,就很容易发现,按业务确实不好拆。但是拆分的纬度不仅仅是业务,还有并发,比如块业务,是读多,还是写多,也可以按照这个纬度来分,在存储层,如果上层用redis做缓存,下层是mysql,也可以按redis拆,还是共mysql库
    架构就是折中。
    2019-10-16
    3
  • xu晓晨
    redis扩展主要两方面。主备方案以及集群方案。
    主备的话可以用redis的sentinel(哨兵)方案主要是解决redis主节点故障后的自动切换。它负责持续监控主从节点的健康,当主节点挂掉时,自动选择一个最优的从节点切换为主节点。
    集群方案的话主流的是两种 一种是codis另一种是redis官方提供的cluster。

    作者回复: 👍

    2019-09-30
    1
    3
  • helloworld
    系统的易扩展之从存储和业务拆分来考虑。业务拆分是容易理解的,专人专事;从存储角度来考虑我想是因为所有应用的功能的最终的结果都是把一些结果存储起来,于是存储就是重点,是重点就必然引起量大,量大了必然成瓶颈。打卡04。

    作者回复: 是的

    2019-10-07
    2
  • Hwan
    看评论说auto shard ,最近在看redis,redis通过哨兵做主从备份和主从迁移,通过集群做增加主节点和减少主节点的事情,基本可以做好自动扩容和缩容了,请问下关系型数据库里面有类似的吗,能够实现自动的扩容之类的,还是说必须需要人工来呢

    作者回复: 需要制定迁移方案,加餐中有介绍哦

    2019-10-29
    1
  • hailong
    为了一个服务就要一个库? 本次课程举的例子一个数据库分不同的表就行了,没懂分库啥意思

    作者回复: 分表的话还是不是在一个机器上,突破不了单机的限制

    2019-10-09
    1
  • 吃饭饭
    两个问题:
    1)尽量不适用事务,这里是不是需要使用分布式事务?类似于使用消息中间件等?
    2)图示中的`池`指的是单个的微服务吗?我第一次听说这个概念,希望老师帮忙回答:)

    作者回复: 1. 其实我还没有遇到什么场景是必须要使用分布式事务的,以前做过的社区产品对一致性的要求不是很高
    2. 池子指的是一组服务器组成的集群,比如用户池就是这个集群只提供用户相关的功能

    2019-10-08
    1
  • Star
    预测未来的数据库一定会综合ES+MONGODB的能力,直接选择库的模式就可以像NOSQL一样使用。

    作者回复: 这样看你团地的运维能力了

    2019-10-02
    1
  • ub8
    坐等干货

    作者回复: :)

    2019-09-28
    1
  • 飞翔
    老师。不太理解什么是池? 用户池 里是一台机器还是多台机器呀?

    作者回复: 池子就是一组机器组成的集群

    2019-09-27
    3
    1
  • 丁丁历险记
    拆分的关键, 信息正交。
    2019-12-02
  • Panda
    拆服务 冷热隔离
    2019-11-29
  • 雷霹雳的爸爸
    按文中描述,如果NoSQL有这种优势得话,应该主要体现在分片和自动数据迁移的能力上,这块儿还真不熟,一直觉得就是支持这两个功能,实现起来也挺难的,有很多的中间状态要考虑对外响应过程中的一致性问题,依然是一个巨大的挑战,先往后看...

    作者回复: 其实也不难,实现方式大同小异

    2019-11-05
  • XD
    redis相关的书籍或者博客有推荐吗?前段时间刚看了一个分布式锁的文章,收获很大。

    作者回复: 可以看看黄建宏的redis设计与实现

    2019-11-01
    2
  • 无形
    对于一个较为复杂的系统,业务上按照功能拆分为不同的子系统,子系统之间解藕,降低整体实现的复杂度,如果子系统是分布式服务,要提高扩展性,要做到服务之间的无状态,解决数据的一致性,请求量大时就能随时扩充机器,提高系统的整体服务能力
    2019-10-31
  • 书中迷梦
    存储层扩展的时候,是不是加个限定词比较好,对于数据不敏感的业务可以考虑不使用事物!而不是直接不使用事物!像支付和订单这些系统,数据肯定需要一致性

    作者回复: 支付需要考虑一致性,订单应该还好

    2019-10-15
  • longslee
    nosql数据库扩容缩容,都是涉及到数据的再分配,手段是减少节点变化带来的数据迁移代价,以及减少节点变化造成的缓存失效。 老师我有个问题,有没有哪款产品是基于一致性Hash理论来做的呢,比如Redis是用的Slot,而不是一致性Hash。

    作者回复: 👍

    2019-10-07
  • Alexdown
    老师文中的“可扩展”更侧重于“硬件”,其实还有“软件”方面的——更易于添加新的功能或模块。我看到有的书中将前者称为“可伸缩”,后者称为“可扩展”。另外,系统设计的目标中还可以加上安全性

    作者回复: 软件方面也可以成为可扩展,两者在思想上是一样的

    2019-10-02
    1
收起评论
33
返回
顶部