背景

單位每年都會舉行運動會，有一個2000m長跑的項目，大約每年報名人員為男選手40人，女選手20人，只有一條橡膠跑道。一次比賽10人齊跑，所以至少需要6場比賽。

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

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

1、60人/10人每場 = 6場，至少需要舉行6場

2、總耗時 = 6場 * 0.5h = 3h

所以每年把這個比賽安排在下午3點到6點，是最后一個比賽項目，晚上7點舉行頒獎晚會。這個預(yù)估容量也算合理。

但是今年比較特別，取消了4000米的長跑，所以2000米報名人員激增50人。時間還是下午3點到6點，

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

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

（比如將比賽時間提前，拉長整個比賽的過程時間，或者增加比賽跑到，同時進(jìn)行兩場比賽），就會造成災(zāi)難。

概念

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

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

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

分析過程

理解一些原理

TPS（Transactions Per Second）：每秒事務(wù)數(shù)

QPS（Query Per Second）：每秒請求數(shù)，QPS其實是衡量吞吐量的一個常用指標(biāo)，就是說服務(wù)器在一秒的時間內(nèi)處理了多少個請求。

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

峰值QPS計算：

1、原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間

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

PV（Page View）：頁面訪問量，即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次

UV（Unique Visitor）：獨立訪客，統(tǒng)計1天內(nèi)訪問某站點的用戶數(shù)(以cookie為依據(jù))

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

響應(yīng)時間（RT）：響應(yīng)時間是指系統(tǒng)對請求作出響應(yīng)的時間，一般取平均響應(yīng)時間 

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

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

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

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

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

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

1、臨時的流量變化：比如 618、雙11，新年大促搞活動等場景，預(yù)估我們的流量會大漲，甚至到原來的數(shù)倍。這時候要做好應(yīng)對的措施。

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

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

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

評估的步驟 

1、分析日總訪問量

分析可能的日訪問量，一般系統(tǒng)系統(tǒng)都會提供比較真實的訪問量數(shù)值，基于此，我們需要評估一個活動的訪問量；如果是一個新上線的系統(tǒng)，我們也要評估可能的PV、UV值。

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

舉個例子：

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

2、評估平均訪問量QPS

QPS是每秒請求量,假設(shè)我們一天正常活動時間一般是11個小時多一點,那一天的時間長度以秒為單位:60*60*11 ≈ 4W,  我們再使用日訪問時間再去除以4W總時間即可. 

舉個例子：

我們上面說的兩個小時的活動時間,實際的總訪問量最后確實是200W,

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

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

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

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

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

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

日均QPS為2900，業(yè)務(wù)訪問趨勢圖如下圖，我們來對峰值QPS做一下預(yù)估

從圖中可以看出，峰值QPS大概是均值QPS的2.58倍，日均QPS為2900，于是評估出峰值QPS為2900*2.58=7482。

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

3.2 使用二八法則計算

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

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

4、評估單實例極限承受的QPS

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

我們在一個系統(tǒng)上線前，一般來說是需要進(jìn)行壓力測試,了解她實際的極限值在哪個地方，以我們上面流量圖為例子（日平均QPS為2900，峰值QPS為7500），這個系統(tǒng)的架構(gòu)可能是這樣的：

1、經(jīng)由APP和Web的的請求，會經(jīng)過Nginx均衡到多臺Web站點上去。

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

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

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

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

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

所以我們得到了web單實例極限的QPS是2500。這邊需要下調(diào)，因為我們不建議讓請求響應(yīng)時長接近2S，最好是1S以內(nèi)。所以下調(diào)至2000。 

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

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

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

案例分析

結(jié)合項目：如何計算圖書系統(tǒng)的QPS、峰值QPS、N個實例和并發(fā)數(shù)

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

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

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

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

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

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

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

總結(jié) 

系統(tǒng)設(shè)計容量評估時機(jī)：

1、臨時的流量變化：比如 618、雙11，新年大促搞活動等場景，預(yù)估我們的流量會大漲，甚至到原來的數(shù)倍。這時候要做好應(yīng)對的措施。

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

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

系統(tǒng)設(shè)計容量評估的步驟：

1、分析日總訪問量：產(chǎn)品、運營的評估和線上數(shù)據(jù)的收集

2、評估日平均訪問量QPS：評估運營時間內(nèi)的平均QPS

3、評估高峰區(qū)間的QPS：流量曲線計算 或 28 法則估算

4、性能壓力測試：評估實例能夠承受的極限吞吐量

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

顯然，開頭的運動會如果子報名結(jié)束后能夠根據(jù)報名的人數(shù)對比，重新做容量設(shè)計，提早做好準(zhǔn)備，情況就不會那么糟糕。

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

最新評論