架構與思惟：設計容量，到底有多重要 ？

背景

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

2000米的完成時間要求是20分鐘，超過20分鐘不計數，因此比賽耗時咱們計算爲20分鐘，加上比賽前的動員組織，比賽後的清場，咱們假定每場比賽耗時30分鐘。

如今咱們預估下耗時：

一、60人/10人每場 = 6場，至少須要舉行6場

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

因此每一年把這個比賽安排在下午3點到6點，是最後一個比賽項目，晚上7點舉行頒獎晚會。這個預估容量也算合理。

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

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

這個是咱們單位真實的故事，這就是設計容量，當你的業務場景的容量發生了變化時候，沒有預估到他的變化，以及變化可能產生的影響，沒有按照這個影響及時的作調整

（好比將比賽時間提早，拉長整個比賽的過程時間，或者增長比賽跑到，同時進行兩場比賽），就會形成災難。

概念

何爲設計容量，從技術上說就是運用一些策略對系統容量進行預估的過程。容量設計是架構師必備的技能之一。

他要求咱們分析系統設計容量要求，儘量給出具體數據描述的：數據量、併發量、帶寬、註冊用戶規模、活躍用戶規模、在線用戶規模、消息長度，圖片大小、網盤空間容量，內存CPU容量等。

下面的內容，咱們以 併發 爲例子，看看看具體的分析過程。

分析過程

理解一些原理

TPS（Transactions Per Second）：每秒事務數

QPS（Query Per Second）：每秒請求數，QPS實際上是衡量吞吐量的一個經常使用指標，就是說服務器在一秒的時間內處理了多少個請求。

併發數：併發數是指系統同時能處理的請求數量，這個也是反應了系統的負載能力。

峯值QPS計算：

一、原理：天天80%的訪問集中在20%的時間裏，這20%時間叫作峯值時間

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

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

UV（Unique Visitor）：獨立訪客，統計1天內訪問某站點的用戶數(以cookie爲依據)

吐吞量：吞吐量是指系統在單位時間內處理請求的數量

響應時間（RT）：響應時間是指系統對請求做出響應的時間，通常取平均響應時間 

QPS（每秒查詢數）、TPS（每秒事務數）是吞吐量的經常使用量化指標，另外還有HPS（每秒HTTP請求數）。

QPS（TPS）、併發數、響應時間它們三者之間的關係是：

一、QPS（TPS）= 併發數 / 平均響應時間

二、併發數 = QPS * 平均響應時間 

系統容量評估時機

主要在三種業務場景下須要及時考慮對系統容量進行評估。

一、臨時的流量變化：好比 61八、雙11，新年大促搞活動等場景，預估咱們的流量會大漲，甚至到原來的數倍。這時候要作好應對的措施。

二、初始系統容量評估：假設咱們開發了某個系統，這個系統初始上線，咱們預估他的容量和負載會是多少。

三、容量基數的變化：好比某個系統，他的功能模塊愈來愈多，數據流量愈來愈大，日活指數愈來愈高，迎來了第二波的增加曲線。咱們原來定好的系統容量漸漸的不知足咱們的需求，這時候咱們也要從新評估和擴容。

咱們系統容量評估包括數據量、併發量、帶寬、CPU、MEMORY、DISK等。以併發量爲案例，咱們來講明系統容量評估的方法和步驟。

評估的步驟 

一、分析日總訪問量

分析可能的日訪問量，通常系統系統都會提供比較真實的訪問量數值，基於此，咱們須要評估一個活動的訪問量；若是是一個新上線的系統，咱們也要評估可能的PV、UV值。

產品、運營部門也須要給出可能的訪問預期值。

舉個例子：

咱們活動期間(9點~10點)會推送2000W的應用消息，假設用戶實際點進去查看的比列爲1/10，那麼這個活動期間(1小時)新增的訪問量就有 2000W * 1/10= 200W

二、評估平均訪問量QPS

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

舉個例子：

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

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

一個成熟系統日QPS也能夠預估 ,好比 百度首頁的日PV數量爲 5000W,按照咱們說的常規活動時間4W秒算,就是5000W / 4W = 1250 QPS.

三、評估高峯區間的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)  

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

可使用壓測(nGrinder 或者 jmeter)方式來獲取單個系統實例的QPS極限值,咱們團隊的標準是當請求響應時間超過2S的時候,已經達到了瓶頸值，並影響使用,須要進行優化和擴容。 

咱們在一個系統上線前，通常來講是須要進行壓力測試,瞭解她實際的極限值在哪一個地方，以咱們上面流量圖爲例子（日平均QPS爲2900，峯值QPS爲7500），這個系統的架構多是這樣的：

 

一、經由APP和Web的的請求，會通過Nginx均衡到多臺Web站點上去。

二、Web集羣會調用並落地到Service集羣上

三、Service集羣向數據層請求數據，正常狀況下其中90%會落到Cache集羣中

四、Cache集羣中不存在（假設10%），會進入DB集羣去訪問數據庫。

咱們經過壓測數據發現，web層是瓶頸，tomcat壓測單個實例只能支持2500的QPS。

Cache集羣和DB集羣足夠強悍，可以輕鬆應對峯值7500的QPS，按比例分別是7500*0.9=6750 和 7500*0.1=750.

 

因此咱們獲得了web單實例極限的QPS是2500。這邊須要下調，由於咱們不建議讓請求響應時長接近2S，最好是1S之內。因此下調至2000。 

五、根據線上冗餘度最終確認

經過上面的計算，咱們已經獲得了峯值QPS是7500，單個實例可以順暢承載QPS是2000，那麼 Web集羣中至少有4個實例可以承接這樣的請求洪峯。

 

除此以外，其餘類型的的容量預估，如數據量、帶寬、CPU、MEMORY、DISK等均可以採用相似策略。

案例分析

結合項目：如何計算圖書系統的QPS、峯值QPS、N個實例和併發數

一、圖書預約系統的併發數計算： 

1.一、二八法則定理：80%的業務基本都是發生在20% 的時間裏面，如系統有早中晚高峯，歷經9個小時（早上10點到晚上19點），9*3600=32400。

1.二、獲取峯值QPS：公式：( 總PV數 * 80% ) / ( 天天秒數 * 20% ) = 峯值時間每秒請求數(QPS)

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

1.三、併發數 = QPS * 平均響應時間 = 0.5*185 = 92.5 ，矯正爲100

1.四、利用343估算法斷定 154，向上矯正爲200

Pessimism 悲觀	30%	80
Normal 標準	40%	100
Optimism 樂觀	30%	300

最後提供給性能測試QA 的測試標準數據是 建議支持併發 200+，QA最終的測試結果是 該併發下響應時間在 50~100ms

總結 

系統設計容量評估時機：

一、臨時的流量變化：好比 61八、雙11，新年大促搞活動等場景，預估咱們的流量會大漲，甚至到原來的數倍。這時候要作好應對的措施。

二、初始系統容量評估：假設咱們開發了某個系統，這個系統初始上線，咱們預估他的容量和負載會是多少。

三、容量基數的變化：好比某個系統，他的功能模塊愈來愈多，數據流量愈來愈大，日活指數愈來愈高，迎來了第二波的增加曲線。咱們原來定好的系統容量漸漸的不知足咱們的需求，這時候咱們也要從新評估和擴容。

系統設計容量評估的步驟：

一、分析日總訪問量：產品、運營的評估和線上數據的收集

二、評估日平均訪問量QPS：評估運營時間內的平均QPS

三、評估高峯區間的QPS：流量曲線計算 或 28 法則估算

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

五、根據線上冗餘度，與實際的差值進行調整，評估出能承載容量的實際結果值

顯然，開頭的運動會若是子報名結束後可以根據報名的人數對比，從新作容量設計，提前作好準備，狀況就不會那麼糟糕。