欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

架構(gòu)與思維論設(shè)計(jì)容量的重要性

 更新時(shí)間:2022年01月31日 11:11:21   作者:Brand  
這篇文章主要為大家介紹了架構(gòu)與思維中論設(shè)計(jì)容量的重要性詳細(xì)分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪

背景

單位每年都會(huì)舉行運(yùn)動(dòng)會(huì),有一個(gè)2000m長(zhǎng)跑的項(xiàng)目,大約每年報(bào)名人員為男選手40人,女選手20人,只有一條橡膠跑道。一次比賽10人齊跑,所以至少需要6場(chǎng)比賽。

2000米的完成時(shí)間要求是20分鐘,超過(guò)20分鐘不計(jì)數(shù),所以比賽耗時(shí)我們計(jì)算為20分鐘,加上比賽前的動(dòng)員組織,比賽后的清場(chǎng),我們假定每場(chǎng)比賽耗時(shí)30分鐘。

現(xiàn)在我們預(yù)估下耗時(shí):

1、60人/10人每場(chǎng) = 6場(chǎng),至少需要舉行6場(chǎng)

2、總耗時(shí) = 6場(chǎng) * 0.5h = 3h

所以每年把這個(gè)比賽安排在下午3點(diǎn)到6點(diǎn),是最后一個(gè)比賽項(xiàng)目,晚上7點(diǎn)舉行頒獎(jiǎng)晚會(huì)。這個(gè)預(yù)估容量也算合理。

但是今年比較特別,取消了4000米的長(zhǎng)跑,所以2000米報(bào)名人員激增50人。時(shí)間還是下午3點(diǎn)到6點(diǎn),

這個(gè)就有問(wèn)題了,最后為了保證晚會(huì)的正常進(jìn)行,一半的人員的比賽時(shí)間推遲到另外一周的周末,搞得怨聲四起,大罵舉辦的行政部門不講武德。

這個(gè)是我們單位真實(shí)的故事,這就是設(shè)計(jì)容量,當(dāng)你的業(yè)務(wù)場(chǎng)景的容量發(fā)生了變化時(shí)候,沒(méi)有預(yù)估到他的變化,以及變化可能產(chǎn)生的影響,沒(méi)有按照這個(gè)影響及時(shí)的做調(diào)整

(比如將比賽時(shí)間提前,拉長(zhǎng)整個(gè)比賽的過(guò)程時(shí)間,或者增加比賽跑到,同時(shí)進(jìn)行兩場(chǎng)比賽),就會(huì)造成災(zāi)難。

概念

何為設(shè)計(jì)容量,從技術(shù)上說(shuō)就是運(yùn)用一些策略對(duì)系統(tǒng)容量進(jìn)行預(yù)估的過(guò)程。容量設(shè)計(jì)是架構(gòu)師必備的技能之一。

他要求我們分析系統(tǒng)設(shè)計(jì)容量要求,盡可能給出具體數(shù)據(jù)描述的:數(shù)據(jù)量、并發(fā)量、帶寬、注冊(cè)用戶規(guī)模、活躍用戶規(guī)模、在線用戶規(guī)模、消息長(zhǎng)度,圖片大小、網(wǎng)盤空間容量,內(nèi)存CPU容量等。

下面的內(nèi)容,我們以并發(fā)為例子,看看看具體的分析過(guò)程。

分析過(guò)程

理解一些原理

TPS(Transactions Per Second):每秒事務(wù)數(shù)

QPS(Query Per Second):每秒請(qǐng)求數(shù),QPS其實(shí)是衡量吞吐量的一個(gè)常用指標(biāo),就是說(shuō)服務(wù)器在一秒的時(shí)間內(nèi)處理了多少個(gè)請(qǐng)求。

并發(fā)數(shù):并發(fā)數(shù)是指系統(tǒng)同時(shí)能處理的請(qǐng)求數(shù)量,這個(gè)也是反應(yīng)了系統(tǒng)的負(fù)載能力。

峰值QPS計(jì)算:

1、原理:每天80%的訪問(wèn)集中在20%的時(shí)間里,這20%時(shí)間叫做峰值時(shí)間

2、公式:( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時(shí)間每秒請(qǐng)求數(shù)(QPS)

PV(Page View):頁(yè)面訪問(wèn)量,即頁(yè)面瀏覽量或點(diǎn)擊量,用戶每次刷新即被計(jì)算一次

UV(Unique Visitor):獨(dú)立訪客,統(tǒng)計(jì)1天內(nèi)訪問(wèn)某站點(diǎn)的用戶數(shù)(以cookie為依據(jù))

吐吞量:吞吐量是指系統(tǒng)在單位時(shí)間內(nèi)處理請(qǐng)求的數(shù)量

響應(yīng)時(shí)間(RT):響應(yīng)時(shí)間是指系統(tǒng)對(duì)請(qǐng)求作出響應(yīng)的時(shí)間,一般取平均響應(yīng)時(shí)間 

QPS(每秒查詢數(shù))、TPS(每秒事務(wù)數(shù))是吞吐量的常用量化指標(biāo),另外還有HPS(每秒HTTP請(qǐng)求數(shù))。

QPS(TPS)、并發(fā)數(shù)、響應(yīng)時(shí)間它們?nèi)咧g的關(guān)系是:

1、QPS(TPS)= 并發(fā)數(shù) / 平均響應(yīng)時(shí)間

2、并發(fā)數(shù) = QPS * 平均響應(yīng)時(shí)間 

系統(tǒng)容量評(píng)估時(shí)機(jī)

主要在三種業(yè)務(wù)場(chǎng)景下需要及時(shí)考慮對(duì)系統(tǒng)容量進(jìn)行評(píng)估。

1、臨時(shí)的流量變化:比如 618、雙11,新年大促搞活動(dòng)等場(chǎng)景,預(yù)估我們的流量會(huì)大漲,甚至到原來(lái)的數(shù)倍。這時(shí)候要做好應(yīng)對(duì)的措施。

2、初始系統(tǒng)容量評(píng)估:假設(shè)我們開(kāi)發(fā)了某個(gè)系統(tǒng),這個(gè)系統(tǒng)初始上線,我們預(yù)估他的容量和負(fù)載會(huì)是多少。

3、容量基數(shù)的變化:比如某個(gè)系統(tǒng),他的功能模塊越來(lái)越多,數(shù)據(jù)流量越來(lái)越大,日活指數(shù)越來(lái)越高,迎來(lái)了第二波的增長(zhǎng)曲線。我們?cè)瓉?lái)定好的系統(tǒng)容量漸漸的不滿足我們的需求,這時(shí)候我們也要重新評(píng)估和擴(kuò)容。

我們系統(tǒng)容量評(píng)估包括數(shù)據(jù)量、并發(fā)量、帶寬、CPU、MEMORY、DISK等。以并發(fā)量為案例,我們來(lái)說(shuō)明系統(tǒng)容量評(píng)估的方法和步驟。

評(píng)估的步驟 

1、分析日總訪問(wèn)量

分析可能的日訪問(wèn)量,一般系統(tǒng)系統(tǒng)都會(huì)提供比較真實(shí)的訪問(wèn)量數(shù)值,基于此,我們需要評(píng)估一個(gè)活動(dòng)的訪問(wèn)量;如果是一個(gè)新上線的系統(tǒng),我們也要評(píng)估可能的PV、UV值。

產(chǎn)品、運(yùn)營(yíng)部門也需要給出可能的訪問(wèn)預(yù)期值。

舉個(gè)例子:

我們活動(dòng)期間(9點(diǎn)~10點(diǎn))會(huì)推送2000W的應(yīng)用消息,假設(shè)用戶實(shí)際點(diǎn)進(jìn)去查看的比列為1/10,那么這個(gè)活動(dòng)期間(1小時(shí))新增的訪問(wèn)量就有 2000W * 1/10= 200W

2、評(píng)估平均訪問(wèn)量QPS

QPS是每秒請(qǐng)求量,假設(shè)我們一天正?;顒?dòng)時(shí)間一般是11個(gè)小時(shí)多一點(diǎn),那一天的時(shí)間長(zhǎng)度以秒為單位:60*60*11 ≈ 4W,  我們?cè)偈褂萌赵L問(wèn)時(shí)間再去除以4W總時(shí)間即可. 

舉個(gè)例子:

我們上面說(shuō)的兩個(gè)小時(shí)的活動(dòng)時(shí)間,實(shí)際的總訪問(wèn)量最后確實(shí)是200W,

那么平均訪問(wèn)量QPS為:200W/(60*60)=555.5 QPS.

一個(gè)成熟系統(tǒng)日QPS也可以預(yù)估 ,比如 百度首頁(yè)的日PV數(shù)量為 5000W,按照我們說(shuō)的常規(guī)活動(dòng)時(shí)間4W秒算,就是5000W / 4W = 1250 QPS.

3、評(píng)估高峰區(qū)間的QPS

我們?cè)谧鱿到y(tǒng)容量規(guī)劃時(shí),不僅僅是考慮平均QPS,最重要的是要承受住高峰區(qū)間的QPS,這個(gè)數(shù)據(jù)可以根據(jù)業(yè)務(wù)流量監(jiān)控的曲線和28法則來(lái)評(píng)估,我們來(lái)看下具體是怎么做的? 

3.1 業(yè)務(wù)流量監(jiān)控的曲線

以下面這個(gè)云系統(tǒng)作為例子:

日均QPS為2900,業(yè)務(wù)訪問(wèn)趨勢(shì)圖如下圖,我們來(lái)對(duì)峰值QPS做一下預(yù)估

從圖中可以看出,峰值QPS大概是均值QPS的2.58倍,日均QPS為2900,于是評(píng)估出峰值QPS為2900*2.58=7482。

這種是日常流量情況,如果遇到很特別的業(yè)務(wù),比如競(jìng)拍\搶訂\秒殺情況,流量幅度還是比較大的.

3.2 使用二八法則計(jì)算

何為二八法則:80%的業(yè)務(wù)基本都是發(fā)生在20%的時(shí)間里面,所以有如下:

峰值QPS公式:( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時(shí)間每秒請(qǐng)求數(shù)(QPS)  

4、評(píng)估單實(shí)例極限承受的QPS

可以使用壓測(cè)(nGrinder 或者 jmeter)方式來(lái)獲取單個(gè)系統(tǒng)實(shí)例的QPS極限值,我們團(tuán)隊(duì)的標(biāo)準(zhǔn)是當(dāng)請(qǐng)求響應(yīng)時(shí)間超過(guò)2S的時(shí)候,已經(jīng)達(dá)到了瓶頸值,并影響使用,需要進(jìn)行優(yōu)化和擴(kuò)容。 

我們?cè)谝粋€(gè)系統(tǒng)上線前,一般來(lái)說(shuō)是需要進(jìn)行壓力測(cè)試,了解她實(shí)際的極限值在哪個(gè)地方,以我們上面流量圖為例子(日平均QPS為2900,峰值QPS為7500),這個(gè)系統(tǒng)的架構(gòu)可能是這樣的:

1、經(jīng)由APP和Web的的請(qǐng)求,會(huì)經(jīng)過(guò)Nginx均衡到多臺(tái)Web站點(diǎn)上去。

2、Web集群會(huì)調(diào)用并落地到Service集群上

3、Service集群向數(shù)據(jù)層請(qǐng)求數(shù)據(jù),正常情況下其中90%會(huì)落到Cache集群中

4、Cache集群中不存在(假設(shè)10%),會(huì)進(jìn)入DB集群去訪問(wèn)數(shù)據(jù)庫(kù)。

我們通過(guò)壓測(cè)數(shù)據(jù)發(fā)現(xiàn),web層是瓶頸,tomcat壓測(cè)單個(gè)實(shí)例只能支持2500的QPS。

Cache集群和DB集群足夠強(qiáng)悍,能夠輕松應(yīng)對(duì)峰值7500的QPS,按比例分別是7500*0.9=6750 和 7500*0.1=750.

所以我們得到了web單實(shí)例極限的QPS是2500。這邊需要下調(diào),因?yàn)槲覀儾唤ㄗh讓請(qǐng)求響應(yīng)時(shí)長(zhǎng)接近2S,最好是1S以內(nèi)。所以下調(diào)至2000。 

5、根據(jù)線上冗余度最終確認(rèn)

通過(guò)上面的計(jì)算,我們已經(jīng)得到了峰值QPS是7500,單個(gè)實(shí)例能夠順暢承載QPS是2000,那么Web集群中至少有4個(gè)實(shí)例能夠承接這樣的請(qǐng)求洪峰。

除此之外,其他類型的的容量預(yù)估,如數(shù)據(jù)量、帶寬、CPU、MEMORY、DISK等都可以采用類似策略。

案例分析

結(jié)合項(xiàng)目:如何計(jì)算圖書(shū)系統(tǒng)的QPS、峰值QPS、N個(gè)實(shí)例和并發(fā)數(shù)

1、圖書(shū)預(yù)定系統(tǒng)的并發(fā)數(shù)計(jì)算: 

1.1、二八法則定理:80%的業(yè)務(wù)基本都是發(fā)生在20% 的時(shí)間里面,如系統(tǒng)有早中晚高峰,歷經(jīng)9個(gè)小時(shí)(早上10點(diǎn)到晚上19點(diǎn)),9*3600=32400。

1.2、獲取峰值QPS:公式:( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時(shí)間每秒請(qǐng)求數(shù)(QPS)

即 ( 1500000 * 80% ) / ( 32400 * 20% ) = 600000/6480≈185/秒

1.3、并發(fā)數(shù) = QPS * 平均響應(yīng)時(shí)間 = 0.5*185 = 92.5 ,矯正為100

1.4、利用343估算法判定 154,向上矯正為200

Pessimism 悲觀

30%

80

Normal 標(biāo)準(zhǔn)

40%

100

Optimism 樂(lè)觀

30%

300

最后提供給性能測(cè)試QA 的測(cè)試標(biāo)準(zhǔn)數(shù)據(jù)是 建議支持并發(fā) 200+,QA最終的測(cè)試結(jié)果是 該并發(fā)下響應(yīng)時(shí)間在 50~100ms

總結(jié) 

系統(tǒng)設(shè)計(jì)容量評(píng)估時(shí)機(jī):

1、臨時(shí)的流量變化:比如 618、雙11,新年大促搞活動(dòng)等場(chǎng)景,預(yù)估我們的流量會(huì)大漲,甚至到原來(lái)的數(shù)倍。這時(shí)候要做好應(yīng)對(duì)的措施。

2、初始系統(tǒng)容量評(píng)估:假設(shè)我們開(kāi)發(fā)了某個(gè)系統(tǒng),這個(gè)系統(tǒng)初始上線,我們預(yù)估他的容量和負(fù)載會(huì)是多少。

3、容量基數(shù)的變化:比如某個(gè)系統(tǒng),他的功能模塊越來(lái)越多,數(shù)據(jù)流量越來(lái)越大,日活指數(shù)越來(lái)越高,迎來(lái)了第二波的增長(zhǎng)曲線。我們?cè)瓉?lái)定好的系統(tǒng)容量漸漸的不滿足我們的需求,這時(shí)候我們也要重新評(píng)估和擴(kuò)容。

系統(tǒng)設(shè)計(jì)容量評(píng)估的步驟:

1、分析日總訪問(wèn)量:產(chǎn)品、運(yùn)營(yíng)的評(píng)估和線上數(shù)據(jù)的收集

2、評(píng)估日平均訪問(wèn)量QPS:評(píng)估運(yùn)營(yíng)時(shí)間內(nèi)的平均QPS

3、評(píng)估高峰區(qū)間的QPS:流量曲線計(jì)算 或 28 法則估算

4、性能壓力測(cè)試:評(píng)估實(shí)例能夠承受的極限吞吐量

5、根據(jù)線上冗余度,與實(shí)際的差值進(jìn)行調(diào)整,評(píng)估出能承載容量的實(shí)際結(jié)果值

顯然,開(kāi)頭的運(yùn)動(dòng)會(huì)如果子報(bào)名結(jié)束后能夠根據(jù)報(bào)名的人數(shù)對(duì)比,重新做容量設(shè)計(jì),提早做好準(zhǔn)備,情況就不會(huì)那么糟糕。

以上就是架構(gòu)與思維論設(shè)計(jì)容量的重要性的詳細(xì)內(nèi)容,更多關(guān)于架構(gòu)思維設(shè)計(jì)容量重要性的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • Postman 使用指南及小技巧

    Postman 使用指南及小技巧

    Postman 簡(jiǎn)化了構(gòu)建 API 的每個(gè)步驟,并簡(jiǎn)化了協(xié)作,這樣就可以更快地創(chuàng)建 API。接下來(lái)通過(guò)本文給大家介紹Postman 使用指南及小技巧,感興趣的朋友跟隨小編一起看看吧
    2021-12-12
  • HTTP協(xié)議詳解_動(dòng)力節(jié)點(diǎn)Java學(xué)院整理

    HTTP協(xié)議詳解_動(dòng)力節(jié)點(diǎn)Java學(xué)院整理

    這篇文章主要介紹了HTTP協(xié)議詳解,超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議,它允許將超文本標(biāo)記語(yǔ)言(HTML)文檔從Web服務(wù)器傳送到客戶端的瀏覽器
    2017-07-07
  • 值得推薦的Idea十幾大優(yōu)秀插件(小結(jié))

    值得推薦的Idea十幾大優(yōu)秀插件(小結(jié))

    這篇文章主要介紹了值得推薦的Idea十幾大優(yōu)秀插件,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧
    2021-04-04
  • php asp.net 比較 [推薦]

    php asp.net 比較 [推薦]

    如今當(dāng)提到 Web 開(kāi)發(fā)時(shí),您有許多選擇。這些方法中許多都涉及到預(yù)處理 - 即,利用特定的標(biāo)記將代碼嵌入到 HTML 頁(yè)面中
    2009-06-06
  • 詳解如何將本地項(xiàng)目上傳到Github的方法步驟(圖文)

    詳解如何將本地項(xiàng)目上傳到Github的方法步驟(圖文)

    這篇文章主要介紹了詳解如何將本地項(xiàng)目上傳到Github的方法步驟(圖文),小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧
    2018-09-09
  • 關(guān)于提交項(xiàng)目到gitee報(bào)錯(cuò)Push to origin/master was rejected的問(wèn)題

    關(guān)于提交項(xiàng)目到gitee報(bào)錯(cuò)Push to origin/master was rejected的問(wèn)題

    這篇文章主要介紹了提交項(xiàng)目到gitee報(bào)錯(cuò)Push to origin/master was rejected的解決辦法,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2020-10-10
  • cnblogs 運(yùn)行代碼功能嘗試

    cnblogs 運(yùn)行代碼功能嘗試

    cnblogs 運(yùn)行代碼功能嘗試,使用cnblogs的朋友可以參考下。
    2011-08-08
  • 解決IDEA中編輯HTML格式文件不自動(dòng)縮進(jìn)問(wèn)題

    解決IDEA中編輯HTML格式文件不自動(dòng)縮進(jìn)問(wèn)題

    這篇文章主要介紹了解決IDEA中編輯HTML格式文件不自動(dòng)縮進(jìn)問(wèn)題,本文內(nèi)容簡(jiǎn)短,解決方法給大家提出了,需要的朋友可以參考下
    2020-01-01
  • 玩轉(zhuǎn)VSCode插件之Remote-SSH的使用情況

    玩轉(zhuǎn)VSCode插件之Remote-SSH的使用情況

    這篇文章主要介紹了玩轉(zhuǎn)VSCode插件之Remote-SSH的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2020-08-08
  • Git常用場(chǎng)景使用方法

    Git常用場(chǎng)景使用方法

    這篇文章主要介紹了Git常用場(chǎng)景使用,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2020-08-08

最新評(píng)論