2019-09-23软件测试是这么写的 可伸缩性和可拓展性
可伸缩性翻译自 Scalability，指的是通过简单地增加硬件配置而使服务处理能力呈线性增长的能力。最简单直观的例子，就是通过在应用服务器集群中增加更多的节点，来提高整个集群的处理能力。
而可扩展性翻译自 Extensibility，指的是网站的架构设计能够快速适应需求的变化，当需要增加新的功能实现时，对原有架构不需要做修改或者做很少的修改就能够快速满足新的业务需求。作者回复: 从你的留言看出，你的知识面确实比较广。
在分布式领域将Scalability翻译成可扩展性的情况确实会更多一些，特别是在工业界。从可扩展性和可伸缩性在搜索引擎中，分别检索出来的结果数可以窥见一斑。
即便是严肃的学术界，我们也会看到可扩展性与可伸缩性互换表示Scalability的场景，比方说经典的两本分布式教材中，《分布式系统概念与设计》使用了可伸缩性的翻译（见原书1.5.4节），而《分布式系统原理与范型》使用了可扩展性的翻译（见原书1.2.4节）。
这种现象告诉我们不能教条的去照搬书上的东西，必须既要结合具体语境去理解问题，更要结合具体的问题去寻找最佳方案。
Robic，谢谢你的抛砖引玉！ 9 30
2019-09-24离开响应时间的要求是无法衡量QPS的，例如一个每秒处理100个查寻且99%响应时间200秒的系统，同样可以每秒处理1000个查询且99%响应时间1秒。如果继续放松对响应时间的要求，每秒处理查询数峰值可能到达5000，但99%响应时间已经到了无法忍受的程度，所以QPS不能被定为5000。作者回复: 首先非常感谢你的留言。肯定是像你说的这样，离开了约束去谈任何指标都是没有意义的。这也是我为什么在文章中谈到各种指标会相互制约、相互冲突的原因。所以，你的回复也是在一定程度上回复了我在文末留下的思考题。
在这里，我替所有的订阅者感谢你精彩的回复！！！ 1 13- 2019-09-24把QPS解释成每秒处理的查询数是有问题的，应该解释为可确保某给定响应时间下的每秒到达的查询数的上限。例如，某单核系统在99%分位200ms响应时间的要求下，系统最多能承受1000个查询，则QPS为1K, 而不是5。
作者回复: 再次感谢你的留言。正如刚才我讲到的：离开了约束去谈任何指标都是没有意义的。在解释BPS的时候，我也提到了查询和查询，事务和事务之间也是不尽相同的。不尽相同的地方也就包括你所说的响应时间。其实影响QPS的不仅仅只是响应时间，还包括其它的约束，如资源占用等。为了不过多影响阅读体验，我并没有把所有的约束放在定义中，而是选择把这个点作为一个课后习题。
在这里，我再次替所有的订阅者感谢你精彩的回复！！！
也欢迎你再次思考文末的问题。期待你更精彩的留言！ 11 - 2019-10-04CAP原理就是讲一个系统无法同时满足一致性，高可用性与分布式。至多只能满足其中2项。单机就是CA一致性且高可用（时间上的高可用，没有同步数据耗时，相同时间可以处理更多问题），如今的分布式肯定是要有P，那么剩下的只能选CP跟AP了。像cdn服务就属于AP高可用且为分布式，像pxc数据库就属于CP一致性且分布式，不知道这样理解对不对？很明显你要满足一致性且分布式就不可能满足高可用，因为同步数据肯定要耗时。其它也一样，不是在于技术是否能实现，而是这个是内在矛盾，不可能通过技术解决，只能取舍。 5
2019-09-24老师今天的东西里面是不是有疏漏啊？吞吐量里面其实就有一对有冲突的：QPS和TPS是很难做到没有没有冲突的；存储中间件/数据系统中大多数都有这种问题，RMDB是最典型的，即使是做了读写分离同样无法解决，故而才会从过去的模式升级出一主多从、双主、、、各种数据模型；甚至我们的硬件磁盘都是读性能远强于写性能。吞吐量内部就有一对互相约束的指标。
资源占用和可用性其实是有约束的：物联网中的这对其实在MQ上上就非常非常明显，不然就不至于需要特意去使用MQTT协议；9月24号《消息队列高手课》中刚好强调了这点。
其它就暂时不知：可能学习学习的还不够深入吧；毕竟学无止尽，觉得明白了一些懂了一些发现还有关联，就像之前的某些课程学习中发现学员感悟其实是另外一门同时在学的老师写的。期待老师答案的揭晓：谢谢老师的教诲。作者回复: 没有问题的哦。我在介绍性能指标刚开始就强调了“不同的系统、服务要达成的目的不同，关注的性能自然也不尽相同”，QPS、TPS作为吞吐量指标当然是性能指标。你的留言质量非常高，从一定程度上也回复了我文末的思考题。
加油！继续保持这种学习+思考+分享的习惯！期待你更多留言！ 5
2019-09-26老师，你讲的很好，对于我这样在门槛边上的初学有很大的指引，我也发现分布式概念太多，内涵很广，如果光是听你的这样的课程，恐怕过不了十节课，就会陷入概念的漩涡，请教下老师，是否有实践性的指导，比如什么实验平台的介绍和操作，让我们能够动手做，这样对我们的认知有很大的帮助。有没有这样的实际操作的平台或者小型操作指导呢？ 3 3
2019-09-29老师的讲解很清晰，知识结构化良好，很赞，感谢！
btw：如果把robustness翻译成“健壮性”就更好了。技术领域本就概念繁多，没必要再徒增烦恼，对新人也不友好。 1
2019-09-29打卡文章学习：
1、分布式系统的衡量指标：性能、资源占用、可用性和可扩展性。
性能：吞吐量（QPS、TPS、BPS）、响应时间、完成时间。
资源占用：系统正常运行占用的硬件资源，比如CPU、内存、硬盘等。
可用性：系统停止时间与总时间的占比，或者某功能失败次数与总请求数据之比衡量。就是我们常说的4个9、5个9。
可扩展性：垂直扩展和水平扩展。
2、不同的分布式场景，所衡量的指标侧重点是不一样的，系统设计时需要有所取舍。展开作者回复: 积跬步，而终至千里！加油！
1
2019-09-24LOT 是什么系统能请教下吗作者回复: 你说的应该是IoT吧？IoT是Internet of Things物联网的缩写
2 1
2020-01-20qps与tps.可用性与可靠性他们互相制约
2020-01-12# 分布式系统的指标
## 前言
分布式系统的出现就是为了用廉价的、普通的机器解决单个计算机处理复杂、大规模数据和任务时存在的性能问题、资源瓶颈问题，以及可用性和可扩展性问题。
特点：
多机器，大规模请求，高性能，资源，可用性，可扩展性。
性能、资源、可用性和可扩展性是分布式系统的重要指标，就是分布式系统的“三围”。
## 性能（Performance）
性能指标，主要用于衡量一个系统处理各种任务的能力。无论是分布式系统还是单机系统，都会对性能有所要求。
### 常见的性能指标
包括吞吐量（Throughput）、响应时间（Response Time）和完成时间（Turnaround Time）。
#### 常见的吞吐量指标
QPS（Queries Per Second）、TPS（Transactions Per Second）和 BPS（Bits Per Second）。
- QPS
QPS，即查询数每秒，用于衡量一个系统每秒处理的查询数。这个指标通常用于读操作，越高说明对读操作的支持越好。
针对于读操作。
- TPS
TPS，即事务数每秒，用于衡量一个系统每秒处理的事务数。这个指标通常对应于写操作，越高说明对写操作的支持越好。
针对于写操作。
- BPS
BPS，即比特数每秒，用于衡量一个系统每秒处理的数据量。
对于一些网络系统、数据管理系统，我们不能简单地按照请求数或事务数来衡量其性能。因为请求与请求、事务与事务之间也存在着很大的差异，比方说，有的事务大需要写入更多的数据。那么在这种情况下，BPS 更能客观地反应系统的吞吐量。
##### 响应时间
系统响应一个请求或输入需要花费的时间。响应时间直接影响到用户体验，对于时延敏感的业务非常重要。
如：
>比如用户搜索导航，特别是用户边开车边搜索的时候，如果
>响应时间很长，就会直接导致用户走错路。
##### 完成时间指
系统真正完成一个请求或处理需要花费的时间。
## 资源占用（Resource Usage）
资源占用指的是，一个系统提供正常能力需要占用的硬件资源，比如 CPU、内存、硬盘等。
### 空载资源占用
一个系统在没有任何负载时的资源占用，叫做空载资源占用体现了这个系统自身的资源占用情况。
### 满额负载
一个系统满额负载时的资源占用，叫做满载资源占用，体现了这个系统全力运行时占用资源的情况，也体现了系统的处理能力。
## 可用性（Availability）
可用性，通常指的是系统在面对各种异常时可以正确提供服务的能力。可用性是分布式系统的一项重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。
#### 计算可用性
1 系统的可用性可以用系统停止服务的时间与总的时间之比衡量
>网站故障/总运行时间 = 不可用
>正常运行/总运行时间 = 可用
2 系统的可用性还可以用某功能的失败次数与总的请求次数之比来衡量
>有 10 次请求失败 对网站请求 1000 次 可用性就是 99%
## 可扩展性（Scalability）
可扩展性，指的是分布式系统通过扩展集群机器规模提高系统性能 (吞吐、响应时间、 完成时间)、存储容量、计算能力的特性，是分布式系统的特有性质。
### 加速比（Speedup）
衡量系统可扩展性的常见指标是加速比（Speedup），也就是一个系统进行扩展后相对扩展前的性能提升。
- 如果你的扩展目标是为了提高系统吞吐量，则可以用扩展后和扩展前的系统吞吐量之比进行衡量。
- 如果你的目标是为了缩短完成时间，则可以用扩展前和扩展后的完成时间之比进行衡量。
## 不同场景下分布式系统的指标
我们都希望自己的分布式系统是高性能、高可用、高扩展和低资源占用的。但出于硬件成本、开发效率等因素的约束，我们无法在性能、可用性、可靠性和资源占用做到面面俱到。
因此，在不同的业务场景中，设计者们需要有所取舍。
如 电商系统
最看重的是吞吐量，为了处理更多的用户访问或订单业务
IoT 物联网系统
设计者最看重的是资源占用指标，
因为在一些功能极简的 IoT 设备上 RAM、ROM 的可用资源通常都是 KB 级的。展开
2019-12-20分布式技术原理与算法#Day2
分布式就是更多的机器处理更多的数据，更复杂的业务。就像算法要先知道时间复杂度与空间复杂度一样，分布式系统也有其评价体系，我们希望的是吃的少跑得快跑不死的马🐴。就是既想马儿跑，又想马儿不吃草，还想马儿死不了。也就是性能好，资源占用低，高可用的可扩展系统。
性能包括了吞吐量，响应时间和完成时间。读业务关注qps,写业务关注tps，传输关注bps。
资源关注cpu ram 磁盘 gpu ssd等等，用得越少越好，要看系统不跑的空载占用，也要看系统跑到极限的满载占用。
可用性就是系统的故障率，越小越可用，这里还有个可靠性的概念，可以理解为可靠性对标的硬件，但硬件的不可靠会带来系统的不可用，因此经常模糊。
可扩展性就不用说了，是分布式的初衷，但好的分布式系统是线性扩展的，即数量增加一倍，性能提升一倍，但这仅仅是理想情况。
当然不可能有上面提到的神马，一定是有取舍的，跑得快一般吃得多，吃得多容易死得早，而活得久又不能跑太快，要看关注点。展开作者回复: 优秀，总结的非常好，这个马的比喻确实很形象！
2019-11-16性能和资源相互制约的，提高性能一种手段就是增加资源，但是系统希望使用更少资源来完成任务。可用性和资源相互制约的，可用性是通过冗余解决的，系统希望使用更少资源来完成任务。
2019-10-30我看，高性能与资源占用是矛盾的，高可用与易扩展也是矛盾的。
2019-10-27置顶留言的可扩展性和可伸缩性，我觉得都挺重要的，重点不在于怎么翻译，而在于理解二者之间的差别，以"横纵优化带来的性能提升"更容易量化作为指标合适，而"业务更新接入时原有系统快速适应匹配的能力"是分布式系统开发要考虑的，但没有确切的量化纬度
2019-10-27可用性和可扩展性，以及低资源使用率，很多时候为了降低完成时间，会不断去优化业务结构和方式，也会导致资源使用率升高。可扩展性，当集群规模越来越大，可用性也会随之降低。
2019-10-20回顾一下衡量分布式系统的三个指标：
1.性能：吞吐量（qps，tps，bps）、响应时间，完成时间；
2.资源占用：空负载占用资源，满负载占用资源；
3.可用性和可扩展性：可用性和可扩展性。可用性可以用5个9，4个9这样的时间指标来衡量，硬件层面理解成可靠性，软件层面理解成可用性；可扩展性是通过硬件的数量的水平伸缩是不是能线性的提升分布式系统的性能。
第一点比较熟悉；第二点平时很少从资源利用率方面来考量；第三点可用性比较熟悉，我们公司今年一直在做业务连续性的整改，这个和系统的可用性可以类比，只是业务连续性是针对更大的宏观视角；
我的疑惑：系统的扩展性除了是硬件资源的水平伸缩，是不是还要考虑软件层面的扩展性，业务层面是不是支持；展开
2019-10-18可扩展性的衡量标准：加速比，扩展完之后的性能提升- 2019-10-18首先，吞吐量的概念，从网卡层面来讲，是不是指的是单位时间内in 和 out的总和？？
一定的条件下。吞吐量高了，会占用更多的资源：cpu、网卡、内存等等，那么会导致响应时间降低，这种就是相互制约 
2019-10-14性能和资源间存在冲突。 要更高的性能，很多情况是需要投入更多资源的，当然也可以从算法或者技术架构上去做优化。分布式旅游可扩展和高可用的特性，所以分布式系统中一般资源的投入对性能的提升是最直接的，到这个可扩展一般也是有约束的，比如一个hadoop集群扩展到1万个节点，那可能就会出现别的问题了。