吞吐量（TPS）、QPS、并发数、响应时间（RT）概念

峰值QPS

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。

公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。

机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。

每天300w PV 的在单台机器上，这台机器需要多少QPS？

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。

一般需要达到139QPS，因为是峰值。

QPS 

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

每秒查询率

因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，其即为QPS。

对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

计算机语言

一种计算机编程语言。用于数据分析和报表产出。运作的平台是MRDCL。支持的数据文件包括ASC格式和CSI格式。

其中CSI格式为QPS独有数据格式。是极其专业的用于数据分析、数据清理和报表产出的语言，目前应用最广的是市场调研行业。中国国内运用的相对比较少。

开发的原因，需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科，记录如下：
1. 响应时间(RT)
　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

3. 并发用户数
　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

4. QPS每秒查询率(Query Per Second)
　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量） 

---

下面说一些我自身的理解：

QPS主要是由服务器的性能（CUP、内存、带宽）来决定，至于QPS的具体评定，需要通过实际项目的压测来进行评定，可以通过jmeter来进行测试，设定测试数量，并不断提高测试并发量，观察服务器资源消耗，直至临界点，此时的并发数即为服务对应的QPS。实际中我们也可以通过逆推的方式计算出目前支撑到的最大性能，可以通过请求最高峰的时间段除以相应的时间，即可得到目前QPS（并非实际性能）。服务对外性能是根据总体服务性能来决定的，假如单个服务器为200QPS，一共有6台，那么实际对外能力为1200QPS。

那么在服务器资源有限的情况下，如何保证服务稳定不奔溃呢？

1.负载均衡：如果服务器性能不同，我们可以通过负载均衡来调整各个服务器的请求，性能高的可以分配更高比例的请求；提到这边，我当时跟同事提到一点，微服务的注册中心也可以进行负载均衡，但是微服务的负载均衡更多的是重业务角度来进行考虑的，当然，也可以进行资源均衡，只不过这不是最主要的。

2.限流：通过限流，使最大请求限定在服务器能够接受的范围内，从而保证服务稳定。这里我了解到的有两种限流方式：一、nginx层限流，通过配置nginx来限定指定请求的请求评率限制请求流量；二、网关限流，在学习微服务的过程中，使用到了zuul网关组件，在前置过滤器中，使用guava中的RateLimiter进行令牌发放，每秒发放指定数量的令牌，拿到令牌的才能请求成功，一旦令牌全部发放，后续请求将无法进行。

---

2020.12.4

今日遇到压测，此处在记录下对QPS及并发数的理解。QPS指的是服务器在规定时间内的处理能力，如服务每秒能够处理1900条请求；看QPS的大小要跟服务的配置结合起来，不能脱离配置谈QPS。并发并不是一个时间内的请求，并发指的是一瞬间的请求，如300个用户同时点击下鼠标发出请求。

下图，为模拟的并发压测，横轴：并发1~6是逐渐增加的，纵轴：0~200，代表的QPS变化。可以看到，最高点为200，这代表我们服务的最高处理能力为200QPS；可以很明显的注意到一点，在这之后QPS下降，这是因为在达到最高处理性能之后，再接入更多请求（此时要建立更多连接），会损耗系统性能，此时的处理能力反而会下跌，并发5的情形下还不如并发4的情形下处理的请求多，这个时候会有部分请求不处理直接返回503服务端错误。另外，有些客户要我们告知并发，此时并不是告知他们最高并发数，而是要结合我们的用户数来告知，比如最高并发为50，我们有5个客户，那可以说10并发。

最后，注意一点：：：我们一般告知用户QPS，这是因为在项目中遇到这样的情况：我们告知了用户一个并发数，正常请求ok没问题，但是这个用户他请求频率过高，后面导致好多请求无效。所以，脱离QPS去谈并发，那就是耍流氓，我哪知道你请求频率多高。

以上为查阅资料以及询问之后的个人理解，如有不当之处，还请指出。