商品秒殺QPS/TPS分析
QPS：Queries Per Second意思是“每秒查詢率”，是一臺伺服器每秒能夠相應的查詢次數，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。
每秒查詢率QPS是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統伺服器的機器的效能經常用每秒查詢率來衡量。
原理：每天80%的訪問集中在20%的時間裡，這20%時間叫做峰值時間
公式：( 總PV數80% ) / ( 每天秒數 20% ) = 峰值時間每秒請求數(QPS)
機器：峰值時間每秒QPS / 單臺機器的QPS = 需要的機器
問：每天300w PV 的在單臺機器上，這臺機器需要多少QPS？
答：( 30000000.8 ) / (86400 0.2 ) = 139 (QPS)
問：如果一臺機器的QPS是58，需要幾臺機器來支援？
答：139 / 58 = 3
TPS
TPS:Transactions Per Second的縮寫，也就是事務數/秒，這個完整的事務包括了使用者請求伺服器，伺服器內部處理，伺服器返回資訊給使用者三個過程。它是軟體測試結果的測量單位。一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些資訊來估計得分。客戶機使用加權協函式平均方法來計算客戶機的得分，測試軟體就是利用客戶機的這些資訊使用加權協函式平均方法來計算伺服器端的整體TPS得分。
區別和聯絡
Qps基本類似於Tps，但是不同的是，對於一個頁面的一次訪問，形成一個Tps；但一次頁面請求，可能產生多次對伺服器的請求，伺服器對這些請求，就可計入“Qps”之中。
例如：訪問一個頁面會請求伺服器3次，一次訪問，產生一個“T”，產生3個“Q”
以上內容摘自ofollow,noindex">QPS和TPS理解，區別和計算方法
實戰統計
來看下目前筆者公司電商專案的QPS
有秒殺活動時候單臺伺服器的全天介面請求數量：467887
按照上述計算QPS的規則
( 4678870.8 ) / (86400 0.2 ) = 21.66 (QPS)
那麼秒殺究竟看的是什麼指標？上述看到的是一整天的平均QPS
秒殺活動，可能活動持續10秒，但是商品太少1秒內就搶光了，那麼在這個秒殺活動的併發量集中發生和提現在了頭1秒，其餘的9秒也有qps，但遠不及頭1秒爆發給系統所帶來的衝擊大，但最後運營統計的話，他統計的是10秒的量，比如這10秒總共是10w的量，那麼就是能夠承受10w的併發系統，雖然可能頭1秒就承擔了6w的qps。
如何得到請求最高峰時期的QPS，可使用命令統計access日誌
zcat access.2018-09-21.log.gz | grep 'url=[a-zA-Z0-9&%_./-~-]*.[html|json]' | awk -F '###' '{print $(3)}' | sort | uniq -c | sort -n -r | head -5
- 其中 grep ‘url=’是為了過濾js，css等請求
- awk -F ‘###’ 的作用是筆者的日誌檔案的分隔符為###，以此切分
- {print $(3)} 切分之後 輸出第三個位置 這個位置筆者的為時間
- head -5 拿出前5條
輸出資料如下：
440 requestTime=[21/Sep/2018:21:00:14 +0800] 394 requestTime=[21/Sep/2018:21:00:07 +0800] 381 requestTime=[21/Sep/2018:21:00:18 +0800] 379 requestTime=[21/Sep/2018:21:00:22 +0800] 379 requestTime=[21/Sep/2018:21:00:10 +0800]
可以發現秒殺高峰單臺伺服器每秒的QPS達到440
分析這一秒鐘的請求 大部分為請求redis的限流請求，試想如果沒有合理的限流機制，全部落到controller處理，最終轉到庫的壓力，嚴重會導致服務宕機不可用。
如何實現秒殺限流呢？可以參照筆者的另一篇文章最簡單有效的秒殺限流
後面會分析tomcat執行緒池，Nginx如何實現負載均衡等 敬請期待
本文為lemon原創文章
著作權歸原作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。