分布式技术原理与算法解析
聂鹏程
智载云帆CTO,前华为分布式Lab资深技术专家
立即订阅
5969 人已学习
课程目录
已更新 36 讲 / 共 34 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 四纵四横,带你透彻理解分布式技术
免费
01 | 分布式缘何而起:从单兵,到游击队,到集团军
02 | 分布式系统的指标:啥是分布式的三围
第一站:分布式协调与同步 (6讲)
03 | 分布式互斥:有你没我,有我没你
04 | 分布式选举:国不可一日无君
05 | 分布式共识:存异求同
06 | 分布式事务:All or nothing
07 | 分布式锁:关键重地,非请勿入
08 | 分布式技术是如何引爆人工智能的?
第二站:分布式资源管理与负载调度 (6讲)
09 | 分布式体系结构之集中式结构:一人在上,万人在下
10 | 分布式体系结构之非集中式结构:众生平等
11 | 分布式调度架构之单体调度:物质文明、精神文明一手抓
12 | 分布式调度架构之两层调度:物质文明、精神文明两手抓
13 | 分布式调度架构之共享状态调度:物质文明、精神文明多手协商抓
14 | 答疑篇:分布式事务与分布式锁相关问题
第三站:分布式计算技术 (4讲)
15 | 分布式计算模式之MR:一门同流合污的艺术
16 | 分布式计算模式之Stream:一门背锅的艺术
17 | 分布式计算模式之Actor:一门甩锅的艺术
18 | 分布式计算模式之流水线:你方唱罢我登场
第四站:分布式通信技术 (4讲)
19 | 分布式通信之远程调用:我是你的千里眼
20 | 分布式通信之发布订阅:送货上门
21 | 分布式通信之消息队列:货物自取
22 | 答疑篇:分布式体系架构与分布式计算相关问题
第五站:分布式数据存储 (5讲)
23 | CAP理论:这顶帽子我不想要
24 | 分布式数据存储系统之三要素:顾客、导购与货架
25 | 数据分布方式之哈希与一致性哈希:“掐指一算”与“掐指两算”的事
26 | 分布式数据复制技术:分身有术
27 | 分布式数据之缓存技术:“身手钥钱”随身带
特别放送 (3讲)
特别放送 | 分布式下的一致性杂谈
特别放送 | 徐志强:学习这件事儿,不到长城非好汉
特别放送 | 那些你不能错过的分布式系统论文
第六站:分布式高可靠 (5讲)
28 | 分布式高可靠之负载均衡:不患寡,而患不均
29 | 分布式高可靠之流量控制:大禹治水,在疏不在堵
30 | 分布式高可用之故障隔离:当断不断,反受其乱
31 | 分布式高可用之故障恢复:知错能改,善莫大焉
32 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

02 | 分布式系统的指标:啥是分布式的三围

聂鹏程 2019-09-23
你好,我是聂鹏程。
在上一篇文章中,通过对分布式发展历程的学习,我们对分布式技术有了一个整体印象。接下来,我们就再来看看可以用哪些指标去具体地衡量一个分布式系统。如果你已经对分布式系统的指标了解得很清楚了,可以直接跳过这篇文章,学习下一讲的内容。

分布式系统的指标

从分布式技术的起源可以看出,分布式系统的出现就是为了用廉价的、普通的机器解决单个计算机处理复杂、大规模数据和任务时存在的性能问题、资源瓶颈问题,以及可用性和可扩展性问题。换句话说,分布式的目的是用更多的机器,处理更多的数据和更复杂的任务。
由此可以看出,性能、资源、可用性和可扩展性是分布式系统的重要指标。没错,它们就是分布式系统的“三围”。接下来,我们一起来看看这几个指标吧。

性能(Performance)

性能指标,主要用于衡量一个系统处理各种任务的能力。无论是分布式系统还是单机系统,都会对性能有所要求。
不同的系统、服务要达成的目的不同,关注的性能自然也不尽相同,甚至是相互矛盾。常见的性能指标,包括吞吐量(Throughput)、响应时间(Response Time)和完成时间(Turnaround Time)。
吞吐量指的是,系统在一定时间内可以处理的任务数。这个指标可以非常直接地体现一个系统的性能,就好比在客户非常多的情况下,要评判一个银行柜台职员的办事效率,你可以统计一下他在 1 个小时内接待了多少客户。常见的吞吐量指标有 QPS(Queries Per Second)、TPS(Transactions Per Second)和 BPS(Bits Per Second)。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(25)

  • Robic
    软件测试是这么写的 可伸缩性和可拓展性
    可伸缩性翻译自 Scalability,指的是通过简单地增加硬件配置而使服务处理能力呈线性增长的能力。最简单直观的例子,就是通过在应用服务器集群中增加更多的节点,来提高整个集群的处理能力。

    而可扩展性翻译自 Extensibility,指的是网站的架构设计能够快速适应需求的变化,当需要增加新的功能实现时,对原有架构不需要做修改或者做很少的修改就能够快速满足新的业务需求。

    作者回复: 从你的留言看出,你的知识面确实比较广。

    在分布式领域将Scalability翻译成可扩展性的情况确实会更多一些,特别是在工业界。从可扩展性和可伸缩性在搜索引擎中,分别检索出来的结果数可以窥见一斑。

    即便是严肃的学术界,我们也会看到可扩展性与可伸缩性互换表示Scalability的场景,比方说经典的两本分布式教材中,《分布式系统概念与设计》使用了可伸缩性的翻译(见原书1.5.4节),而《分布式系统原理与范型》使用了可扩展性的翻译(见原书1.2.4节)。

    这种现象告诉我们不能教条的去照搬书上的东西,必须既要结合具体语境去理解问题,更要结合具体的问题去寻找最佳方案。

    Robic,谢谢你的抛砖引玉!

    2019-09-23
    9
    27
  • 开心小毛
    离开响应时间的要求是无法衡量QPS的,例如一个每秒处理100个查寻且99%响应时间200秒的系统,同样可以每秒处理1000个查询且99%响应时间1秒。如果继续放松对响应时间的要求,每秒处理查询数峰值可能到达5000,但99%响应时间已经到了无法忍受的程度,所以QPS不能被定为5000。

    作者回复: 首先非常感谢你的留言。肯定是像你说的这样,离开了约束去谈任何指标都是没有意义的。这也是我为什么在文章中谈到各种指标会相互制约、相互冲突的原因。所以,你的回复也是在一定程度上回复了我在文末留下的思考题。

    在这里,我替所有的订阅者感谢你精彩的回复!!!

    2019-09-24
    1
    12
  • 开心小毛
    把QPS解释成每秒处理的查询数是有问题的,应该解释为可确保某给定响应时间下的每秒到达的查询数的上限。例如,某单核系统在99%分位200ms响应时间的要求下,系统最多能承受1000个查询,则QPS为1K, 而不是5。

    作者回复: 再次感谢你的留言。正如刚才我讲到的:离开了约束去谈任何指标都是没有意义的。在解释BPS的时候,我也提到了查询和查询,事务和事务之间也是不尽相同的。不尽相同的地方也就包括你所说的响应时间。其实影响QPS的不仅仅只是响应时间,还包括其它的约束,如资源占用等。为了不过多影响阅读体验,我并没有把所有的约束放在定义中,而是选择把这个点作为一个课后习题。

    在这里,我再次替所有的订阅者感谢你精彩的回复!!!

    也欢迎你再次思考文末的问题。期待你更精彩的留言!

    2019-09-24
    9
  • leslie
    老师今天的东西里面是不是有疏漏啊?吞吐量里面其实就有一对有冲突的:QPS和TPS是很难做到没有没有冲突的;存储中间件/数据系统中大多数都有这种问题,RMDB是最典型的,即使是做了读写分离同样无法解决,故而才会从过去的模式升级出一主多从、双主、、、各种数据模型;甚至我们的硬件磁盘都是读性能远强于写性能。吞吐量内部就有一对互相约束的指标。
        资源占用和可用性其实是有约束的:物联网中的这对其实在MQ上上就非常非常明显,不然就不至于需要特意去使用MQTT协议;9月24号《消息队列高手课》中刚好强调了这点。
         其它就暂时不知:可能学习学习的还不够深入吧;毕竟学无止尽,觉得明白了一些懂了一些发现还有关联,就像之前的某些课程学习中发现学员感悟其实是另外一门同时在学的老师写的。期待老师答案的揭晓:谢谢老师的教诲。

    作者回复: 没有问题的哦。我在介绍性能指标刚开始就强调了“不同的系统、服务要达成的目的不同,关注的性能自然也不尽相同”,QPS、TPS作为吞吐量指标当然是性能指标。你的留言质量非常高,从一定程度上也回复了我文末的思考题。

    加油!继续保持这种学习+思考+分享的习惯!期待你更多留言!

    2019-09-24
    5
  • Geek_f6f02b
    CAP原理就是讲一个系统无法同时满足一致性,高可用性与分布式。至多只能满足其中2项。单机就是CA一致性且高可用(时间上的高可用,没有同步数据耗时,相同时间可以处理更多问题),如今的分布式肯定是要有P,那么剩下的只能选CP跟AP了。像cdn服务就属于AP高可用且为分布式,像pxc数据库就属于CP一致性且分布式,不知道这样理解对不对?很明显你要满足一致性且分布式就不可能满足高可用,因为同步数据肯定要耗时。其它也一样,不是在于技术是否能实现,而是这个是内在矛盾,不可能通过技术解决,只能取舍。
    2019-10-04
    4
  • 周涛
    老师,你讲的很好,对于我这样在门槛边上的初学有很大的指引,我也发现分布式概念太多,内涵很广,如果光是听你的这样的课程,恐怕过不了十节课,就会陷入概念的漩涡,请教下老师,是否有实践性的指导,比如什么实验平台的介绍和操作,让我们能够动手做,这样对我们的认知有很大的帮助。有没有这样的实际操作的平台或者小型操作指导呢?
    2019-09-26
    3
    3
  • Gopher
    老师的讲解很清晰,知识结构化良好,很赞,感谢!

    btw:如果把robustness翻译成“健壮性”就更好了。技术领域本就概念繁多,没必要再徒增烦恼,对新人也不友好。
    2019-09-29
    1
  • zhaozp
    打卡文章学习:
        1、分布式系统的衡量指标:性能、资源占用、可用性和可扩展性。
    性能:吞吐量(QPS、TPS、BPS)、响应时间、完成时间。
    资源占用:系统正常运行占用的硬件资源,比如CPU、内存、硬盘等。
    可用性:系统停止时间与总时间的占比,或者某功能失败次数与总请求数据之比衡量。就是我们常说的4个9、5个9。
    可扩展性:垂直扩展和水平扩展。
        2、不同的分布式场景,所衡量的指标侧重点是不一样的,系统设计时需要有所取舍。

    作者回复: 积跬步,而终至千里!加油!

    2019-09-29
    1
  • 小美
    LOT 是什么系统能请教下吗

    作者回复: 你说的应该是IoT吧?IoT是Internet of Things物联网的缩写

    2019-09-24
    2
    1
  • 布小丫学编程
    性能和资源相互制约的,提高性能一种手段就是增加资源,但是系统希望使用更少资源来完成任务。可用性和资源相互制约的,可用性是通过冗余解决的,系统希望使用更少资源来完成任务。
    2019-11-16
  • 行下一首歌
    我看,高性能与资源占用是矛盾的,高可用与易扩展也是矛盾的。
    2019-10-30
  • 玖号先生
    置顶留言的可扩展性和可伸缩性,我觉得都挺重要的,重点不在于怎么翻译,而在于理解二者之间的差别,以"横纵优化带来的性能提升"更容易量化作为指标合适,而"业务更新接入时原有系统快速适应匹配的能力"是分布式系统开发要考虑的,但没有确切的量化纬度
    2019-10-27
  • kakaliuu
    可用性和可扩展性,以及低资源使用率,很多时候为了降低完成时间,会不断去优化业务结构和方式,也会导致资源使用率升高。可扩展性,当集群规模越来越大,可用性也会随之降低。
    2019-10-27
  • Eternal
    回顾一下衡量分布式系统的三个指标:
    1.性能:吞吐量(qps,tps,bps)、响应时间,完成时间;
    2.资源占用:空负载占用资源,满负载占用资源;
    3.可用性和可扩展性:可用性和可扩展性。可用性可以用5个9,4个9这样的时间指标来衡量,硬件层面理解成可靠性,软件层面理解成可用性;可扩展性是通过硬件的数量的水平伸缩是不是能线性的提升分布式系统的性能。
       
    第一点比较熟悉;第二点平时很少从资源利用率方面来考量;第三点可用性比较熟悉,我们公司今年一直在做业务连续性的整改,这个和系统的可用性可以类比,只是业务连续性是针对更大的宏观视角;

    我的疑惑:系统的扩展性除了是硬件资源的水平伸缩,是不是还要考虑软件层面的扩展性,业务层面是不是支持;
    2019-10-20
  • 江河顺水
    可扩展性的衡量标准:加速比,扩展完之后的性能提升
    2019-10-18
  • 江河顺水
    首先,吞吐量的概念,从网卡层面来讲,是不是指的是单位时间内in 和 out的总和??
    一定的条件下。吞吐量高了,会占用更多的资源:cpu、网卡、内存等等,那么会导致响应时间降低,这种就是相互制约
    2019-10-18
  • 波波安
    性能和资源间存在冲突。 要更高的性能,很多情况是需要投入更多资源的,当然也可以从算法或者技术架构上去做优化。分布式旅游可扩展和高可用的特性,所以分布式系统中一般资源的投入对性能的提升是最直接的,到这个可扩展一般也是有约束的,比如一个hadoop集群扩展到1万个节点,那可能就会出现别的问题了。
    2019-10-14
  • sky
    老师好:我认为的分布式三围是CAP。不知道老师是讲解的角度不同,还是其它什么?

    作者回复: 本文将的分布式三围指的是分布式的指标,CAP在本专栏归结围分布式系统的特征,具体可参考“23 CAP理论:这顶帽子我不想要”

    2019-10-10
  • 静水流深
    打卡,谢谢老师分享

    作者回复: 不积小流无以成江海,加油!

    2019-10-09
  • Scarf
    您好!请问,正文中的“各系统对于各个指标的要求”这张表格,是不是部分内容有误?正文里说了“吞吐量和完成时间通常是区块链系统设计者的首要目标”,但是表格里面对于区块链里,这两个指标的要求分别是低和中,怎么理解呢?
    2019-10-04
    3
收起评论
25
返回
顶部