不瞭解 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、結束

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

愛生活，愛編碼，微信搜一搜【架構技術專欄】關注這個喜歡分享的地方。
本文 架構技術專欄 已收錄，有各類視頻、資料以及技術文章。