架構與思維論設計容量的重要性
背景
單位每年都會舉行運動會,有一個2000m長跑的項目,大約每年報名人員為男選手40人,女選手20人,只有一條橡膠跑道。一次比賽10人齊跑,所以至少需要6場比賽。
2000米的完成時間要求是20分鐘,超過20分鐘不計數,所以比賽耗時我們計算為20分鐘,加上比賽前的動員組織,比賽后的清場,我們假定每場比賽耗時30分鐘。
現(xiàn)在我們預估下耗時:
1、60人/10人每場 = 6場,至少需要舉行6場
2、總耗時 = 6場 * 0.5h = 3h
所以每年把這個比賽安排在下午3點到6點,是最后一個比賽項目,晚上7點舉行頒獎晚會。這個預估容量也算合理。
但是今年比較特別,取消了4000米的長跑,所以2000米報名人員激增50人。時間還是下午3點到6點,
這個就有問題了,最后為了保證晚會的正常進行,一半的人員的比賽時間推遲到另外一周的周末,搞得怨聲四起,大罵舉辦的行政部門不講武德。
這個是我們單位真實的故事,這就是設計容量,當你的業(yè)務場景的容量發(fā)生了變化時候,沒有預估到他的變化,以及變化可能產生的影響,沒有按照這個影響及時的做調整
(比如將比賽時間提前,拉長整個比賽的過程時間,或者增加比賽跑到,同時進行兩場比賽),就會造成災難。
概念
何為設計容量,從技術上說就是運用一些策略對系統(tǒng)容量進行預估的過程。容量設計是架構師必備的技能之一。
他要求我們分析系統(tǒng)設計容量要求,盡可能給出具體數據描述的:數據量、并發(fā)量、帶寬、注冊用戶規(guī)模、活躍用戶規(guī)模、在線用戶規(guī)模、消息長度,圖片大小、網盤空間容量,內存CPU容量等。
下面的內容,我們以并發(fā)為例子,看看看具體的分析過程。
分析過程
理解一些原理
TPS(Transactions Per Second):每秒事務數
QPS(Query Per Second):每秒請求數,QPS其實是衡量吞吐量的一個常用指標,就是說服務器在一秒的時間內處理了多少個請求。
并發(fā)數:并發(fā)數是指系統(tǒng)同時能處理的請求數量,這個也是反應了系統(tǒng)的負載能力。
峰值QPS計算:
1、原理:每天80%的訪問集中在20%的時間里,這20%時間叫做峰值時間
2、公式:( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
PV(Page View):頁面訪問量,即頁面瀏覽量或點擊量,用戶每次刷新即被計算一次
UV(Unique Visitor):獨立訪客,統(tǒng)計1天內訪問某站點的用戶數(以cookie為依據)
吐吞量:吞吐量是指系統(tǒng)在單位時間內處理請求的數量
響應時間(RT):響應時間是指系統(tǒng)對請求作出響應的時間,一般取平均響應時間
QPS(每秒查詢數)、TPS(每秒事務數)是吞吐量的常用量化指標,另外還有HPS(每秒HTTP請求數)。
QPS(TPS)、并發(fā)數、響應時間它們三者之間的關系是:
1、QPS(TPS)= 并發(fā)數 / 平均響應時間
2、并發(fā)數 = QPS * 平均響應時間
系統(tǒng)容量評估時機
主要在三種業(yè)務場景下需要及時考慮對系統(tǒng)容量進行評估。
1、臨時的流量變化:比如 618、雙11,新年大促搞活動等場景,預估我們的流量會大漲,甚至到原來的數倍。這時候要做好應對的措施。
2、初始系統(tǒng)容量評估:假設我們開發(fā)了某個系統(tǒng),這個系統(tǒng)初始上線,我們預估他的容量和負載會是多少。
3、容量基數的變化:比如某個系統(tǒng),他的功能模塊越來越多,數據流量越來越大,日活指數越來越高,迎來了第二波的增長曲線。我們原來定好的系統(tǒng)容量漸漸的不滿足我們的需求,這時候我們也要重新評估和擴容。
我們系統(tǒng)容量評估包括數據量、并發(fā)量、帶寬、CPU、MEMORY、DISK等。以并發(fā)量為案例,我們來說明系統(tǒng)容量評估的方法和步驟。
評估的步驟
1、分析日總訪問量
分析可能的日訪問量,一般系統(tǒng)系統(tǒng)都會提供比較真實的訪問量數值,基于此,我們需要評估一個活動的訪問量;如果是一個新上線的系統(tǒng),我們也要評估可能的PV、UV值。
產品、運營部門也需要給出可能的訪問預期值。
舉個例子:
我們活動期間(9點~10點)會推送2000W的應用消息,假設用戶實際點進去查看的比列為1/10,那么這個活動期間(1小時)新增的訪問量就有 2000W * 1/10= 200W
2、評估平均訪問量QPS
QPS是每秒請求量,假設我們一天正常活動時間一般是11個小時多一點,那一天的時間長度以秒為單位:60*60*11 ≈ 4W, 我們再使用日訪問時間再去除以4W總時間即可.
舉個例子:
我們上面說的兩個小時的活動時間,實際的總訪問量最后確實是200W,
那么平均訪問量QPS為:200W/(60*60)=555.5 QPS.
一個成熟系統(tǒng)日QPS也可以預估 ,比如 百度首頁的日PV數量為 5000W,按照我們說的常規(guī)活動時間4W秒算,就是5000W / 4W = 1250 QPS.
3、評估高峰區(qū)間的QPS
我們在做系統(tǒng)容量規(guī)劃時,不僅僅是考慮平均QPS,最重要的是要承受住高峰區(qū)間的QPS,這個數據可以根據業(yè)務流量監(jiān)控的曲線和28法則來評估,我們來看下具體是怎么做的?
3.1 業(yè)務流量監(jiān)控的曲線
以下面這個云系統(tǒng)作為例子:
日均QPS為2900,業(yè)務訪問趨勢圖如下圖,我們來對峰值QPS做一下預估
從圖中可以看出,峰值QPS大概是均值QPS的2.58倍,日均QPS為2900,于是評估出峰值QPS為2900*2.58=7482。
這種是日常流量情況,如果遇到很特別的業(yè)務,比如競拍\搶訂\秒殺情況,流量幅度還是比較大的.
3.2 使用二八法則計算
何為二八法則:80%的業(yè)務基本都是發(fā)生在20%的時間里面,所以有如下:
峰值QPS公式:( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
4、評估單實例極限承受的QPS
可以使用壓測(nGrinder 或者 jmeter)方式來獲取單個系統(tǒng)實例的QPS極限值,我們團隊的標準是當請求響應時間超過2S的時候,已經達到了瓶頸值,并影響使用,需要進行優(yōu)化和擴容。
我們在一個系統(tǒng)上線前,一般來說是需要進行壓力測試,了解她實際的極限值在哪個地方,以我們上面流量圖為例子(日平均QPS為2900,峰值QPS為7500),這個系統(tǒng)的架構可能是這樣的:
1、經由APP和Web的的請求,會經過Nginx均衡到多臺Web站點上去。
2、Web集群會調用并落地到Service集群上
3、Service集群向數據層請求數據,正常情況下其中90%會落到Cache集群中
4、Cache集群中不存在(假設10%),會進入DB集群去訪問數據庫。
我們通過壓測數據發(fā)現(xiàn),web層是瓶頸,tomcat壓測單個實例只能支持2500的QPS。
Cache集群和DB集群足夠強悍,能夠輕松應對峰值7500的QPS,按比例分別是7500*0.9=6750 和 7500*0.1=750.
所以我們得到了web單實例極限的QPS是2500。這邊需要下調,因為我們不建議讓請求響應時長接近2S,最好是1S以內。所以下調至2000。
5、根據線上冗余度最終確認
通過上面的計算,我們已經得到了峰值QPS是7500,單個實例能夠順暢承載QPS是2000,那么Web集群中至少有4個實例能夠承接這樣的請求洪峰。
除此之外,其他類型的的容量預估,如數據量、帶寬、CPU、MEMORY、DISK等都可以采用類似策略。
案例分析
結合項目:如何計算圖書系統(tǒng)的QPS、峰值QPS、N個實例和并發(fā)數
1、圖書預定系統(tǒng)的并發(fā)數計算:
1.1、二八法則定理:80%的業(yè)務基本都是發(fā)生在20% 的時間里面,如系統(tǒng)有早中晚高峰,歷經9個小時(早上10點到晚上19點),9*3600=32400。
1.2、獲取峰值QPS:公式:( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
即 ( 1500000 * 80% ) / ( 32400 * 20% ) = 600000/6480≈185/秒
1.3、并發(fā)數 = QPS * 平均響應時間 = 0.5*185 = 92.5 ,矯正為100
1.4、利用343估算法判定 154,向上矯正為200
Pessimism 悲觀 | 30% | 80 |
Normal 標準 | 40% | 100 |
Optimism 樂觀 | 30% | 300 |
最后提供給性能測試QA 的測試標準數據是 建議支持并發(fā) 200+,QA最終的測試結果是 該并發(fā)下響應時間在 50~100ms
總結
系統(tǒng)設計容量評估時機:
1、臨時的流量變化:比如 618、雙11,新年大促搞活動等場景,預估我們的流量會大漲,甚至到原來的數倍。這時候要做好應對的措施。
2、初始系統(tǒng)容量評估:假設我們開發(fā)了某個系統(tǒng),這個系統(tǒng)初始上線,我們預估他的容量和負載會是多少。
3、容量基數的變化:比如某個系統(tǒng),他的功能模塊越來越多,數據流量越來越大,日活指數越來越高,迎來了第二波的增長曲線。我們原來定好的系統(tǒng)容量漸漸的不滿足我們的需求,這時候我們也要重新評估和擴容。
系統(tǒng)設計容量評估的步驟:
1、分析日總訪問量:產品、運營的評估和線上數據的收集
2、評估日平均訪問量QPS:評估運營時間內的平均QPS
3、評估高峰區(qū)間的QPS:流量曲線計算 或 28 法則估算
4、性能壓力測試:評估實例能夠承受的極限吞吐量
5、根據線上冗余度,與實際的差值進行調整,評估出能承載容量的實際結果值
顯然,開頭的運動會如果子報名結束后能夠根據報名的人數對比,重新做容量設計,提早做好準備,情況就不會那么糟糕。
以上就是架構與思維論設計容量的重要性的詳細內容,更多關于架構思維設計容量重要性的資料請關注腳本之家其它相關文章!
相關文章
HTTP協(xié)議詳解_動力節(jié)點Java學院整理
這篇文章主要介紹了HTTP協(xié)議詳解,超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議,它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器2017-07-07關于提交項目到gitee報錯Push to origin/master was rejected的問題
這篇文章主要介紹了提交項目到gitee報錯Push to origin/master was rejected的解決辦法,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-10-10