作者：翁智華
出處：https://www.cnblogs.com/wzh2010/
背景
單位每年都會舉行運動會，有一個2000m長跑的專案，大約每年報名人員為男選手40人，女選手20人，只有一條橡膠跑道，一次比賽10人齊跑，所以至少需要6場比賽，
2000米的完成時間要求是20分鐘，超過20分鐘不計數，所以比賽耗時我們計算為20分鐘，加上比賽前的動員組織，比賽后的清場，我們假定每場比賽耗時30分鐘，
現在我們預估下耗時：
1、60人/10人每場 = 6場，至少需要舉行6場
2、總耗時 = 6場 * 0.5h = 3h
所以每年把這個比賽安排在下午3點到6點，是最后一個比賽專案，晚上7點舉行頒獎晚會，這個預估容量也算合理，
但是今年比較特別，取消了4000米的長跑，所以2000米報名人員激增50人，時間還是下午3點到6點，
這個就有問題了，最后為了保證晚會的正常進行，一半的人員的比賽時間推遲到另外一周的周末，搞得怨聲四起，大罵舉辦的行政部門不講武德，
這個是我們單位真實的故事，這就是設計容量，當你的業務場景的容量發生了變化時候，沒有預估到他的變化，以及變化可能產生的影響，沒有按照這個影響及時的做調整
（比如將比賽時間提前，拉長整個比賽的程序時間，或者增加比賽跑到，同時進行兩場比賽），就會造成災難，
概念
何為設計容量，從技術上說就是運用一些策略對系統容量進行預估的程序，容量設計是架構師必備的技能之一，
他要求我們分析系統設計容量要求，盡可能給出具體資料描述的：資料量、并發量、帶寬、注冊用戶規模、活躍用戶規模、在線用戶規模、訊息長度，圖片大小、網盤空間容量，記憶體CPU容量等，
下面的內容，我們以 并發 為例子，看看看具體的分析程序，
分析程序
理解一些原理
TPS（Transactions Per Second）：每秒事務數
QPS（Query Per Second）：每秒請求數，QPS其實是衡量吞吐量的一個常用指標，就是說服務器在一秒的時間內處理了多少個請求，
并發數：并發數是指系統同時能處理的請求數量，這個也是反應了系統的負載能力，
峰值QPS計算：
1、原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間
2、公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
PV（Page View）：頁面訪問量，即頁面瀏覽量或點擊量，用戶每次重繪即被計算一次
UV（Unique Visitor）：獨立訪客，統計1天內訪問某站點的用戶數(以cookie為依據)
吐吞量：吞吐量是指系統在單位時間內處理請求的數量
回應時間（RT）：回應時間是指系統對請求作出回應的時間，一般取平均回應時間
QPS（每秒查詢數）、TPS（每秒事務數）是吞吐量的常用量化指標，另外還有HPS（每秒HTTP請求數），
QPS（TPS）、并發數、回應時間它們三者之間的關系是：
1、QPS（TPS）= 并發數 / 平均回應時間
2、并發數 = QPS * 平均回應時間
系統容量評估時機
主要在三種業務場景下需要及時考慮對系統容量進行評估，
1、臨時的流量變化：比如 618、雙11，新年大促搞活動等場景，預估我們的流量會大漲，甚至到原來的數倍，這時候要做好應對的措施，
2、初始系統容量評估：假設我們開發了某個系統，這個系統初始上線，我們預估他的容量和負載會是多少，
3、容量基數的變化：比如某個系統，他的功能模塊越來越多，資料流量越來越大，榷訓指數越來越高，迎來了第二波的增長曲線，我們原來定好的系統容量漸漸的不滿足我們的需求，這時候我們也要重新評估和擴容，
我們系統容量評估包括資料量、并發量、帶寬、CPU、MEMORY、DISK等，以并發量為案例，我們來說明系統容量評估的方法和步驟，
評估的步驟
1、分析日總訪問量
分析可能的日訪問量，一般系統系統都會提供比較真實的訪問量數值，基于此，我們需要評估一個活動的訪問量；如果是一個新上線的系統，我們也要評估可能的PV、UV值，
產品、運營部門也需要給出可能的訪問預期值，
舉個例子：
我們活動期間(9點~10點)會推送2000W的應用訊息，假設用戶實際點進去查看的比列為1/10，那么這個活動期間(1小時)新增的訪問量就有 2000W * 1/10= 200W
2、評估平均訪問量QPS
QPS是每秒請求量,假設我們一天正常活動時間一般是11個小時多一點,那一天的時間長度以秒為單位:606011 ≈ 4W, 我們再使用日訪問時間再去除以4W總時間即可.
舉個例子：
我們上面說的兩個小時的活動時間,實際的總訪問量最后確實是200W,
那么平均訪問量QPS為:200W/(60*60)=555.5 QPS.
一個成熟系統日QPS也可以預估 ,比如 百度首頁的日PV數量為 5000W,按照我們說的常規活動時間4W秒算,就是5000W / 4W = 1250 QPS.
3、評估高峰區間的QPS
我們在做系統容量規劃時，不僅僅是考慮平均QPS，最重要的是要承受住高峰區間的QPS，這個資料可以根據業務流量監控的曲線和28法則來評估,我們來看下具體是怎么做的?
3.1 業務流量監控的曲線
以下面這個云系統作為例子：
日均QPS為2900，業務訪問趨勢圖如下圖，我們來對峰值QPS做一下預估
從圖中可以看出，峰值QPS大概是均值QPS的2.58倍，日均QPS為2900，于是評估出峰值QPS為2900*2.58=7482，
這種是日常流量情況,如果遇到很特別的業務,比如競拍\搶訂\秒殺情況,流量幅度還是比較大的.
3.2 使用二八法則計算
何為二八法則:80%的業務基本都是發生在20%的時間里面,所以有如下:
峰值QPS公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
4、評估單實體極限承受的QPS
可以使用壓測(nGrinder 或者 jmeter)方式來獲取單個系統實體的QPS極限值,我們團隊的標準是當請求回應時間超過2S的時候,已經達到了瓶頸值，并影響使用,需要進行優化和擴容，
我們在一個系統上線前，一般來說是需要進行壓力測驗,了解她實際的極限值在哪個地方，以我們上面流量圖為例子（日平均QPS為2900，峰值QPS為7500），這個系統的架構可能是這樣的：
1、經由APP和Web的的請求，會經過Nginx均衡到多臺Web站點上去，
2、Web集群會呼叫并落地到Service集群上
3、Service集群向資料層請求資料，正常情況下其中90%會落到Cache集群中
4、Cache集群中不存在（假設10%），會進入DB集群去訪問資料庫，
我們通過壓測資料發現，web層是瓶頸，tomcat壓測單個實體只能支持2500的QPS，
Cache集群和DB集群足夠強悍，能夠輕松應對峰值7500的QPS，按比例分別是75000.9=6750 和 75000.1=750.
所以我們得到了web單實體極限的QPS是2500，這邊需要下調，因為我們不建議讓請求回應時長接近2S，最好是1S以內，所以下調至2000，
5、根據線上冗余度最終確認
通過上面的計算，我們已經得到了峰值QPS是7500，單個實體能夠順暢承載QPS是2000，那么Web集群中至少有4個實體能夠承接這樣的請求洪峰，
除此之外，其他型別的的容量預估，如資料量、帶寬、CPU、MEMORY、DISK等都可以采用類似策略，
案例分析
結合專案：如何計算圖書系統的QPS、峰值QPS、N個實體和并發數
1、圖書預定系統的并發數計算：
1.1、二八法則定理：80%的業務基本都是發生在20% 的時間里面，如系統有早中晚高峰，歷經9個小時（早上10點到晚上19點），9*3600=32400，
1.2、獲取峰值QPS：公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
即 ( 1500000 * 80% ) / ( 32400 * 20% ) = 600000/6480≈185/秒
1.3、并發數 = QPS * 平均回應時間 = 0.5*185 = 92.5 ，矯正為100
1.4、利用343估演算法判定 154，向上矯正為200
| Pessimism 悲觀 | 30% | 80 |
|---|---|---|
| Normal 標準 | 40% | 100 |
| Optimism 樂觀 | 30% | 300 |
最后提供給性能測驗QA 的測驗標準資料是 建議支持并發 200+，QA最終的測驗結果是 該并發下回應時間在 50~100ms
總結
系統設計容量評估時機：
1、臨時的流量變化：比如 618、雙11，新年大促搞活動等場景，預估我們的流量會大漲，甚至到原來的數倍，這時候要做好應對的措施，
2、初始系統容量評估：假設我們開發了某個系統，這個系統初始上線，我們預估他的容量和負載會是多少，
3、容量基數的變化：比如某個系統，他的功能模塊越來越多，資料流量越來越大，榷訓指數越來越高，迎來了第二波的增長曲線，我們原來定好的系統容量漸漸的不滿足我們的需求，這時候我們也要重新評估和擴容，
系統設計容量評估的步驟：
1、分析日總訪問量：產品、運營的評估和線上資料的收集
2、評估日平均訪問量QPS：評估運營時間內的平均QPS
3、評估高峰區間的QPS：流量曲線計算 或 28 法則估算
4、性能壓力測驗：評估實體能夠承受的極限吞吐量
5、根據線上冗余度，與實際的差值進行調整，評估出能承載容量的實際結果值
顯然，開頭的運動會如果子報名結束后能夠根據報名的人數對比，重新做容量設計，提早做好準備，情況就不會那么糟糕，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288854.html
標籤：其他