架構(gòu)與思維論設(shè)計(jì)容量的重要性
背景
單位每年都會(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)文章
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)秀插件,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2021-04-04詳解如何將本地項(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)題
這篇文章主要介紹了提交項(xiàng)目到gitee報(bào)錯(cuò)Push to origin/master was rejected的解決辦法,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-10-10解決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的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-08-08