高并发系统设计 40 问
唐扬
美图公司技术专家
49013 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
高并发系统设计 40 问
15
15
1.0x
00:00/00:00
登录|注册

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

根据请求来源维度拆分业务池
核心池和非核心池
按业务维度拆分成单独的业务池
避免使用事务
数据库水平拆分
存储拆分首先考虑业务维度
业务层的扩展性
存储层的扩展性
拆分成独立的、有单一职责的模块
拆分是提升系统扩展性的重要思路
系统整体架构角度考虑扩展性
无状态服务易于扩展
存储服务难以扩展
集群系统中存在瓶颈点制约横向扩展能力
单机系统并行任务数增多可能导致性能下降
突发事件可能导致流量瞬间增加
预留冗余以应对峰值流量
可通过增加机器线性提高系统处理能力
高可扩展性的设计思路
重要因素
系统扩展性复杂性
高可扩展性是设计指标
如何让系统易于扩展?
系统设计目标

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

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

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

在上一讲中,我提到可以在单机系统中通过增加处理核心的方式,来增加系统的并行处理能力,但这个方式并不总奏效。因为当并行的任务数较多时,系统会因为争抢资源而达到性能上的拐点,系统处理能力不升反降。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了系统设计中的高可扩展性,着重讨论了通过增加机器来线性提高系统处理能力的方法。作者指出,在架构设计初期难以预测峰值流量,因此需要考虑系统的扩展性。拆分是提升系统扩展性最重要的思路,通过拆分庞杂的系统成独立的、有单一职责的模块,可以简化复杂问题。此外,文章还介绍了存储层和业务层的扩展性设计思路,包括存储层的拆分和业务层的拆分方案。通过这些设计思路,读者可以了解如何在系统设计中提升系统的扩展性,以应对突发的流量和并发。文章还提到了拆分后的系统可能带来的挑战,需要团队做好准备。最后,作者鼓励读者分享这篇文章,以便更多人受益。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(61)

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

    作者回复: 👍👍👍👍

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

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

    2019-09-27
    29
  • YY
    数据库拆分后,但是各个库还是有相互依赖的,比如关系池,内容池都会依赖用户池,这种相互依赖的关系怎么解决?

    作者回复: 梳理依赖关系,如果有相互依赖的话,看看能不能拆出更基础的服务,让其他服务都依赖它

    2019-12-17
    3
    16
  • xu晓晨
    redis扩展主要两方面。主备方案以及集群方案。 主备的话可以用redis的sentinel(哨兵)方案主要是解决redis主节点故障后的自动切换。它负责持续监控主从节点的健康,当主节点挂掉时,自动选择一个最优的从节点切换为主节点。 集群方案的话主流的是两种 一种是codis另一种是redis官方提供的cluster。

    作者回复: 👍

    2019-09-30
    6
    12
  • A.Windy
    这不就是微服务嘛😄

    作者回复: 是的哦

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

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

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

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

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

    作者回复: 是的

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

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

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

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

    2019-09-27
    6
    4
收起评论
显示
设置
留言
61
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部