不了解 QPS、TPS、RT、并发数、吞吐量，劝你简历别写熟悉高并发

爱生活，爱编码，微信搜一搜【架构技术专栏】关注这个喜欢分享的地方。
本文 架构技术专栏 已收录，有各类视频、资料以及技术文章。

1、概述

分布式、微服务、Service Mesh目前都是你们耳熟能详的词语了，如今随便一个互联网公司说出来你们都是在搞微服务。

但咱们搞来搞去，怎么样来衡量一个应用当前的状态究竟是怎么样的？到底需不须要扩容？是须要横向扩容仍是进行项目重构？

这时候咱们就须要一堆监控指标来协助咱们进行分析当前的应用状态，以便在某些事故发生前进行资源上的调配或优化。

下面我们就来讲道说道这几个重要的指标，必定要记牢，无论面试仍是本身用都是必须滴。

要牢记一点，全部的指标都是根据时间单位来算的，好比每秒XX、每分钟XX，要记住这个大前提，下面我们都按秒来算。

2、指标

一、QPS（Queries Per Second）

概念：服务器每秒处理查询次数，是一台服务器每秒可以处理的查询次数。用户发起查询请求到服务器作出响应这算一次，一秒内用户完成了50次查询请求，那此时服务器QPS就是50。

二、TPS （Transactions Per Second）

概念：服务器每秒处理的事务数，一个事物是用户发起查询请求到服务器作出响应这算一次。纳尼？这难道不是QPS的概念吗？划重点，这里就要说清楚一个概念了，在针对单接口，TPS能够认为是等价于QPS的，如访问 ‘order.html’ 这个页面而言,是一个TPS。而访问 ‘order.html’ 页面可能请求了3此服务器（如调用了css、js、order接口），这实际就算产生了三个QPS

因此，总结下就是，在针对单接口的时候TPS = QPS ,不然QPS就要看实际的请求次数了。

二、RT（Res（onse Time）

概念：响应实际，就是从客户端请求发起到服务器响应结果的时间。RT这个参数是系统最重要的指标之一，它的大小直接反应了当前系统的响应状态。基本和我们用户体验息息相关，如今好一点监控系统通常都有三个RT，即平均、最大、最小。

通常系统RT 100ms 之内是比较正常的，300ms 勉强能够接受，1s的话再加上一些其余的外因，给用户的体验就是实实在在的不爽了。

三、并发数

概念：系统能同时处理的请求的数量，不少人常常会把并发数和TPS理解混淆。举例，请求一个index.html 页面，客户端发起了三个请求（css、js、index接口）,那么此时TPS =1 、QPS =3 、并发数 3。

SO，计算公式 ： QPS=并发数/RT || 并发数=QPS*RT

四、吞吐量（Throughput）

概念：每秒承受的用户访问量，吞吐量（系统能承受多少压力）和当前请求对CPU消耗、内存、IO使用等等紧密相关。单个请求消耗越高，系统吞吐量越低，反之越高。

一个系统的吞吐量和其TPS 、QPS、并发数息息相关，每一个系统针对这些值都有一个相对极限值，只要其中某一个达到最大，系统的吞吐量也就到达极限了。如此时压力继续增大，系统的吞吐量反而会降低，缘由是系统超负荷工做，各类资源切换等等的消耗致使系统性能降低。

关系：

因此，理解上面几个关系后，就能够推算出：

QPS（TPS）= 并发数/平均响应时间

五、PV（Page View）

概念： 即每一个页面的浏览次数，用户每次刷新就算一次。

六、UV（Unique Visitor）

概念：独立访客数，天天访问的用户数，此数据须要根据用户惟一标识进行去重。

七、Load（系统负载）

概念：此数据指的是Linux系统的负载状况，也就是我们平时所用Top命令时，最上面显示的数据信息( load average: 0.1, 0.2, 0.5)。此时会显示1分钟、5分钟、15分钟的系统平均Load，很显然load average 的值越低，你的系统负荷越小。

简单的说下这个值应该怎么看，若是你是单核cpu,那此值为1的时候就是系统已经满负荷状态了，须要你立刻去解决。但实际经验告诉咱们，当系统负荷持续大于0.7的时候（也就是70%），就须要你立刻来解决问题了，防止进一步恶化。

为何须要三个值 load average: 0.1, 0.2, 0.5，其实就是给你个参考。好比只有1分钟的是1，其余俩都是0.1，这代表只是临时突发的现象，问题不大。若是15分钟内，系统负荷都是1或大于1，那代表问题持续存在啊。因此你应该主要观察15分钟的系统负荷。

3、结束

好了，简单又开心的概念说完了。能够继续进行个人王者大业了，荣耀王者在等待着我。

爱生活，爱编码，微信搜一搜【架构技术专栏】关注这个喜欢分享的地方。
本文 架构技术专栏 已收录，有各类视频、资料以及技术文章。