一、前言
在做一個系統前，首先要思考，這個系統將來有多少人用，最高併發有多少。用戶規模和併發的不同，會決定系統架構的不同。架構決定成本，包括開發和運行成本，不要一味的追求高性能，適用最好。
二、基礎概念
1. 註冊用戶數、在線用戶數、併發用戶數
- 註冊用戶數：一般指的是數據庫中存在的用戶數
- 在線用戶數：只是 ”掛” 在系統上，對服務器不產生壓力
- 併發用戶數：一定會對服務器產生壓力的
2. 併發用戶數、併發數、QPS、RPS
- 併發用戶數：在一段時間內集中使用系統的用戶數
- 併發數：系統同時處理的請求數（取決於cpu核數）
- QPS：Queries Per Second每秒鐘請求數，QPS = 併發數/平均響應時間 = 併發用戶數/（平均思考時間+平均響應時間）
- RPS：Request Per Second每秒鐘請求數（與QPS完全等價）
併發用戶數和併發數常常混用，但是實際上，一般表達的是併發用戶數的意思。（產品所說的系統並發表示併發用戶數）
併發數和QPS常常混用，但是實際上，一般表達的是QPS的意思。（研發所說的系統並發表示QPS）
真正的系統併發取決於硬件，不會隨意變化，沒有討論意義。
如何知道系統的QPS？
- 壓測
- 估算：響應時間取倒數
假設我們當前一個http請求服務器處理完成需要100ms（即平均響應時間 = 100ms ）。那麼它1s鍾可以處理10個請求，也就是 qps = 10。
3. QPS、TPS
- QPS：Queries Per Second，指服務器每秒處理的事務次數。一般用於評估數據庫、交易系統的基準性能。
- TPS：Transactions Per Second，是服務器每秒能夠處理的查詢次數，例如域名服務器、Mysql查詢性能。
人們常常將兩者混用，在不特殊強調的情況下，可以粗略的認爲兩者是等價的，通用的。
但是實際上，至少從字面意思上，兩者的含義是不同的
- 第一種解釋： QPS是針對網絡服務器，TPS適用於所有服務器；討論網絡服務器時，QPS=TPS
- 第二種解釋： QPS只是請求數，有可能多個請求纔可以完成一個事務；在這種解釋下，QPS≥TPS
- 第三種解釋： QPS是請求總數，TPS是訪問數據庫或者開啓事務的請求數；在這種解釋下，QPS≥TPS
- 第四種解釋： QPS是查詢次數，TPS是訪問數據庫或者開啓事務的請求數；在這種解釋下，QPS表示讀，TPS表示寫
可以看出QPS一般沒有歧義，問題主要在於如何解釋TPS定義中的“事務”。所以建議統一使用QPS，除非QPS特別不符合語境時再使用TPS。
4. 吞吐量
系統在單位時間內處理請求的數量。只不過是一個很寬泛的術語，大家經常指的吞吐量的單位可能是：TPS/QPS、頁面數/秒、人數/天、處理業務數/小時等等。
5. 響應時間、思考時間
- 響應時間：Response Time，服務器處理一次請求所用的時間
- 思考時間：Think Time，用戶兩次請求的間隔時間，用戶觸發一次請求所需要的時間（填一個表單需要5分鐘，也就是最多每5分鐘才能觸發一次請求）
三、最大併發用戶數估算（最多支持多少個人同時使用系統）
1. 在做系統之前，根據產品需求（最多支持多少個人同時使用系統），可以得出一個目標QPS作爲系統的性能目標。
（1）已知最大在線用戶數
最大併發用戶數 = 系統最大在線用戶數的8%到12%
最大QPS = 最大併發用戶數 / (平均思考時間+平均響應時間)
原理：在線的用戶裏，最多有8%到12%的用戶會同時操作
（2）對於一天當中用戶登錄時間不長，且分佈比較均勻的系統來說
平均併發用戶數 = (一天的在線用戶數*平均用戶登錄時長) / 一天當中用戶可能使用系統的時間區間
最大併發用戶數 = 平均併發用戶數 + 3*(平均併發用戶數開根號)
原理：粗略認爲，峯值比平均值高出3倍的根號平均值
舉例1：
假設系統A，該系統有3000個用戶，平均每天大概有400個用戶要訪問該系統，對於一個典型用戶來說，一天之內用戶從登陸到退出的平均時間爲4小時，而在一天之內，用戶只有在8小時之內會使用該系統。
–
平均併發用戶數 = 400*4/8 = 200
最大併發用戶數 = 200 + 3*根號200 = 243
舉例2：
某公司爲其170000名員工設計了一個薪酬系統，員工可進入該系統查詢自己的薪酬信息，但並不是每個人都會用這個系統，假設只有50%的人會定期用改系統，這些人裏面有70%是在每個月的最後一週使用一次該系統，且平均使用系統時間爲5分鐘。該公司朝九晚五，每天工作8小時。
–
最後一週的使用系統的用戶數 = 170000*0.5*0.7 = 59500
最後一週的平均每天使用系統的用戶數（一週5個工作日） = 59500/5 = 11900
最後一週的平均每天用戶使用系統的分鐘數（平均使用系統時間爲5分鐘） = 11900*5 = 59500
最後一週的每天平均併發用戶數（一天8個工時） = 59500/(8*60) = 124
最後一週的每天最大併發用戶數 = 124 + 3*根號124 = 138
（3）對於一天當中用戶請求比較集中的系統來說，適合直接估算QPS，再估算最大併發用戶數
最大QPS = 一天的用戶請求數*80% / 用戶集中時間段
最大併發用戶數 = 最大QPS * (平均思考時間+平均響應時間)
原理：根據2/8原則，認爲80%的用戶請求都會在集中的時間段裏完成；通常平均思考時間設爲2，平均響應時間設爲1
舉例1：
假設一個網站，每天的PV大概1000w，根據2/8原則，我們可以認爲這1000w pv的80%是在一天的9個小時內完成的。
–
最大QPS = 1000w*80%/(9*3600) = 246.92個/s
最大併發用戶數 = 246.92*3 = 740
舉例2：
以乘坐地鐵爲例子，每天乘坐人數爲5萬人次，每天早高峯是7到9點，晚高峯是6到7點，根據8/2原則，80%的乘客會在高峯期間乘坐地鐵。
–
最大QPS（每秒到達地鐵檢票口的人數） = 爲50000*80%/（3*60*60）=3.7，約4人/s
考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數肯定比這個要大，假定每個人需要3秒（平均思考時間+平均響應時間爲3秒）
最大併發用戶數 = 4人/s*3s = 12人
2. 在做系統之後，通過性能測試可以知道系統的最大QPS，從而估算最多支持多少個人同時使用系統。
最大併發用戶數 = 最大QPS * (平均思考時間+平均響應時間)
通常平均思考時間設爲2，平均響應時間設爲1