一. 基本概念
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 : 原創部落格請在轉載時保留原文連結或在文章開頭加上本人部落格位址，否則保留追究法律責任的權利。