一. 基本概念
1.QPS(Queries Per Second)
A. 指每秒查詢率，是一台服務器每秒能夠響應的查詢次數（數據庫中的每秒執行查詢sql的次數)。
B. 是數據庫中的概念，每秒執行條數（查詢），被引申到壓測中來了，但是不包括插入、更新、刪除操作，所以不建議用qps來描述系統整體的性能。
2.TPS(Transactions Per Second)
A. 指每秒事務數，具體事務的定義，都是人為的，可以一個接口、多個接口、一個業務流程等等。一個事務是指事務內第一個請求發送到接收到最后一個請求的響應的過程，以此來計算使用的時間和完成的事務個數。
B. 以單接口定義為事務為例，每個事務包括了如下3個過程： 如果每秒能夠完成N次這三個過程，tps就是N.
a.向服務器發請求
b.服務器自己的內部處理（包含應用服務器、數據庫服務器等）
c.服務器返回結果給客戶端
C. 如果多個接口定義為一個事務，那么，會重復執行abc，完成一次這幾個請求，算做一個tps.
3.QPS和TPS對別
A. 如果一個接口是單場景的查詢接口,且接口內部不再請求其它接口,此時QPS=TPS.
B. 如果一個接口內部請求了n個其它單一的查詢接口,此時QPS=n * TPS.
C. 如果沒有特別定義事務，會把1個http請求作為1個事務，即1個QPS可能包括多個TPS.
PS. Jmeter中的Throughput，即吞吐量，也就是TPS, 這里TPS = 樣本總數/運行時間。
4. 響應時間(RT)
執行一個請求從開始到最后收到響應數據所花費的總體時間,即從客戶端發起請求到收到服務器響應結果的時間。響應時間RT(Response-Time)，是一個系統最重要的指標之一，它的數值大小直接反應了系統的快慢。
5. 並發數
並發數是指系統同時能處理的請求數量（即1個時間段內系統能處理的請求總數），這個也是反應了系統的負載能力。
6. 吞吐量
A.含義：吞吐量是指系統在單位時間內能處理請求的數量，TPS、QPS都是吞吐量的常用量化指標.
B.一個系統的吞吐量（承壓能力）與request（請求）對cpu的消耗，外部接口，IO等等緊密關聯。單個request 對cpu消耗越高，外部系統接口，IO影響速度越慢，系統吞吐能力越低，反之越高。
7. 擴展
TPS=並發數/平均響應時間
二. 業務分析
1.背景說明
某商城在雙十一的0點對部分商品進行秒殺促銷活動，秒殺持續一個小時，如果提前賣完則秒殺結束，1小時后商品恢復原價， 預估峰值為2000並發。
2.具備的資源
A. 最多兩台服務器(2核8G 5M帶寬),可以Win系統 或 Centos系統
B. 數據庫可以用 SQLServer 或 MySQL
C. 技術人員和運維人員各1名
3. 需達到目標
A. 1s能處理1000個並發
B. 秒殺期間服務不能宕機
C. 用戶體驗要友好,不能出現頁面長時間卡頓假死現象(自身的設備或者網絡條件差除外)
4.可能遇到的問題
(1).正常搶單的人數超過預期值2000
(2).出現了黃牛屯單現象
(3).用戶的網絡存在延遲或者下單設備卡頓
(4).不法分子大量惡意請求
(5).商品受歡迎程度不同,比如搶A的非常多,搶B的相對少一些
(6).服務宕機
三. 單體架構搭建
1.技術選型
A. 數據庫：SQLServer 2014
B. 緩存：Redis緩存 + （服務端緩存）
C. 消息隊列： RabbitMQ
D. 負載均衡：Nginx
E. 服務器：WinServer 2016
F. 阿里雲CDN
G. 基礎框架：Asp.Net Core + EFCore + xxxx
2.DB設計
詳見《數據庫設計說明書》，主要包括用戶表、商品表、訂單表、支付記錄表、秒殺商品表、秒殺時間模型表.
3.架構圖
后續和最終微服務架構圖一塊補充
4.空接口測試
前提：將IIS的隊列長度改為足夠大，比如改為：65535，其它配置不做調整。
測試：分析結果90%的百分位，統計2s下能處理並發請求數，要求異常率為0.
測試結果：多次取平均值，2s內能處理的並發請求數約為2400，如下圖：
6.數據准備
A.用戶表：id=100001
B.商品表：id=200001
C.秒殺商品表：id=300001、articleId=200001、articleStockNum=10000、limitNum=10(隨時改)
注：接下來的6節主要演示演變過程,單純從技術上實現,不考慮太多規范問題。
!
- 作 者 : Yaopengfei(姚鵬飛)
- 博客地址 : http://www.cnblogs.com/yaopengfei/
- 聲 明1 : 如有錯誤，歡迎討論，請勿謾罵^_^。
- 聲 明2 : 原創博客請在轉載時保留原文鏈接或在文章開頭加上本人博客地址，否則保留追究法律責任的權利。