不了解 QPS、TPS、RT、并發數、吞吐量，勸你履歷别寫熟悉高并發

愛生活，愛編碼，微信搜一搜【架構技術專欄】關注這個喜歡分享的地方。

本文

架構技術專欄 已收錄，有各種視訊、資料以及技術文章。

一、概述

分布式、微服務、Service Mesh目前都是大家耳熟能詳的詞語了，現在随便一個網際網路公司說出來大家都是在搞微服務。

但我們搞來搞去，怎麼樣來衡量一個應用目前的狀态到底是怎麼樣的？到底需不需要擴容？是需要橫向擴容還是進行項目重構？

這時候我們就需要一堆監控名額來協助我們進行分析目前的應用狀态，以便在某些事故發生前進行資源上的調配或優化。

下面咱們就來說道說道這幾個重要的名額，一定要記牢，不管面試還是自己用都是必須滴。

要牢記一點，所有的名額都是根據時間機關來算的，比如每秒XX、每分鐘XX，要記住這個大前提，下面咱們都按秒來算。

二、名額

1、QPS（Queries Per Second）

概念：伺服器每秒處理查詢次數，是一台伺服器每秒能夠處理的查詢次數。使用者發起查詢請求到伺服器做出響應這算一次，一秒内使用者完成了50次查詢請求，那此時伺服器QPS就是50。

2、TPS （Transactions Per Second）

概念：伺服器每秒處理的事務數，一個事物是使用者發起查詢請求到伺服器做出響應這算一次。納尼？這難道不是QPS的概念嗎？劃重點，這裡就要說清楚一個概念了，在針對單接口，TPS可以認為是等價于QPS的，如通路 ‘order.html’ 這個頁面而言,是一個TPS。而通路 ‘order.html’ 頁面可能請求了3此伺服器（如調用了css、js、order接口），這實際就算産生了三個QPS

是以，總結下就是，在針對單接口的時候TPS = QPS ,否則QPS就要看實際的請求次數了。

2、RT（Res（onse Time）

概念：響應實際，就是從用戶端請求發起到伺服器響應結果的時間。RT這個參數是系統最重要的名額之一，它的大小直接反應了目前系統的響應狀态。基本和咱們使用者體驗息息相關，現在好一點監控系統一般都有三個RT，即平均、最大、最小。

一般系統RT 100ms 以内是比較正常的，300ms 勉強可以接受，1s的話再加上一些其他的外因，給使用者的體驗就是實實在在的不爽了。

3、并發數

概念：系統能同時處理的請求的數量，很多人經常會把并發數和TPS了解混淆。舉例，請求一個index.html 頁面，用戶端發起了三個請求（css、js、index接口）,那麼此時TPS =1 、QPS =3 、并發數 3。

SO，計算公式 ： QPS=并發數/RT || 并發數=QPS*RT

4、吞吐量（Throughput）

概念：每秒承受的使用者通路量，吞吐量（系統能承受多少壓力）和目前請求對CPU消耗、記憶體、IO使用等等緊密相關。單個請求消耗越高，系統吞吐量越低，反之越高。

一個系統的吞吐量和其TPS 、QPS、并發數息息相關，每個系統針對這些值都有一個相對極限值，隻要其中某一個達到最大，系統的吞吐量也就到達極限了。如此時壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，各種資源切換等等的消耗導緻系統性能下降。

關系：

是以，了解上面幾個關系後，就可以推算出：

QPS（TPS）= 并發數/平均響應時間

5、PV（Page View）

概念： 即每個頁面的浏覽次數，使用者每次重新整理就算一次。

6、UV（Unique Visitor）

概念：獨立訪客數，每天通路的使用者數，此資料需要根據使用者唯一辨別進行去重。

7、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分鐘的系統負荷。

三、結束

好了，簡單又開心的概念說完了。可以繼續進行我的王者大業了，榮耀王者在等待着我。