架構與思維：設計容量，到底有多重要 ？
背景
單位每年都會舉行運動會，有一個 2000m 長跑的項目，大約每年報名人員爲男選手 40 人，女選手 20 人，只有一條橡膠跑道。一次比賽 10 人齊跑，所以至少需要 6 場比賽。
2000 米的完成時間要求是 20 分鐘，超過 20 分鐘不計數，所以比賽耗時我們計算爲 20 分鐘，加上比賽前的動員組織，比賽後的清場，我們假定每場比賽耗時 30 分鐘。
現在我們預估下耗時：
1、60 人 / 10 人每場 = 6 場，至少需要舉行 6 場
2、總耗時 = 6 場 * 0.5h = 3h
所以每年把這個比賽安排在下午 3 點到 6 點，是最後一個比賽項目，晚上 7 點舉行頒獎晚會。這個預估容量也算合理。
但是今年比較特別，取消了 4000 米的長跑，所以 2000 米報名人員激增 50 人。時間還是下午 3 點到 6 點，
這個就有問題了，最後爲了保證晚會的正常進行，一半的人員的比賽時間推遲到另外一週的週末，搞得怨聲四起，大罵舉辦的行政部門不講武德。
這個是我們單位真實的故事，這就是設計容量，當你的業務場景的容量發生了變化時候，沒有預估到他的變化，以及變化可能產生的影響，沒有按照這個影響及時的做調整
（比如將比賽時間提前，拉長整個比賽的過程時間，或者增加比賽跑到，同時進行兩場比賽），就會造成災難。
概念
何爲設計容量，從技術上說就是運用一些策略對系統容量進行預估的過程。容量設計是架構師必備的技能之一。
他要求我們分析系統設計容量要求，儘可能給出具體數據描述的：數據量、併發量、帶寬、註冊用戶規模、活躍用戶規模、在線用戶規模、消息長度，圖片大小、網盤空間容量，內存 CPU 容量等。
下面的內容，我們以 併發 爲例子，看看看具體的分析過程。
分析過程
理解一些原理
TPS（Transactions Per Second）：每秒事務數
QPS（Query Per Second）：每秒請求數，QPS 其實是衡量吞吐量的一個常用指標，就是說服務器在一秒的時間內處理了多少個請求。
併發數：併發數是指系統同時能處理的請求數量，這個也是反應了系統的負載能力。
峯值 QPS 計算：
1、原理：每天 80% 的訪問集中在 20% 的時間裏，這 20% 時間叫做峯值時間
2、公式：(總 PV 數 * 80%) / ( 每天秒數 * 20% ) = 峯值時間每秒請求數 (QPS)
PV（Page View）：頁面訪問量，即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次
UV（Unique Visitor）：獨立訪客，統計 1 天內訪問某站點的用戶數 (以 cookie 爲依據)
吐吞量：吞吐量是指系統在單位時間內處理請求的數量
響應時間（RT）：響應時間是指系統對請求作出響應的時間，一般取平均響應時間
QPS（每秒查詢數）、TPS（每秒事務數）是吞吐量的常用量化指標，另外還有 HPS（每秒 HTTP 請求數）。
QPS（TPS）、併發數、響應時間它們三者之間的關係是：
1、QPS（TPS）= 併發數 / 平均響應時間
2、併發數 = QPS * 平均響應時間
系統容量評估時機
主要在三種業務場景下需要及時考慮對系統容量進行評估。
1、臨時的流量變化：比如 618、雙 11，新年大促搞活動等場景，預估我們的流量會大漲，甚至到原來的數倍。這時候要做好應對的措施。
2、初始系統容量評估：假設我們開發了某個系統，這個系統初始上線，我們預估他的容量和負載會是多少。
3、容量基數的變化：比如某個系統，他的功能模塊越來越多，數據流量越來越大，日活指數越來越高，迎來了第二波的增長曲線。我們原來定好的系統容量漸漸的不滿足我們的需求，這時候我們也要重新評估和擴容。
我們系統容量評估包括數據量、併發量、帶寬、CPU、MEMORY、DISK 等。以併發量爲案例，我們來說明系統容量評估的方法和步驟。
評估的步驟
1、分析日總訪問量
分析可能的日訪問量，一般系統系統都會提供比較真實的訪問量數值，基於此，我們需要評估一個活動的訪問量；如果是一個新上線的系統，我們也要評估可能的 PV、UV 值。
產品、運營部門也需要給出可能的訪問預期值。
舉個例子：
我們活動期間 (9 點~ 10 點) 會推送 2000W 的應用消息，假設用戶實際點進去查看的比列爲 1/10，那麼這個活動期間 (1 小時) 新增的訪問量就有 2000W * 1/10= 200W
2、評估平均訪問量 QPS
QPS 是每秒請求量, 假設我們一天正常活動時間一般是 11 個小時多一點, 那一天的時間長度以秒爲單位: 606011 ≈ 4W, 我們再使用日訪問時間再去除以 4W 總時間即可.
舉個例子：
我們上面說的兩個小時的活動時間, 實際的總訪問量最後確實是 200W,
那麼平均訪問量 QPS 爲: 200W/(60*60)=555.5 QPS.
一個成熟系統日 QPS 也可以預估 , 比如 百度首頁的日 PV 數量爲 5000W, 按照我們說的常規活動時間 4W 秒算, 就是 5000W / 4W = 1250 QPS.
3、評估高峯區間的 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)
4、評估單實例極限承受的 QPS
可以使用壓測 (nGrinder 或者 jmeter) 方式來獲取單個系統實例的 QPS 極限值, 我們團隊的標準是當請求響應時間超過 2S 的時候, 已經達到了瓶頸值，並影響使用, 需要進行優化和擴容。
我們在一個系統上線前，一般來說是需要進行壓力測試, 瞭解她實際的極限值在哪個地方，以我們上面流量圖爲例子（日平均 QPS 爲 2900，峯值 QPS 爲 7500），這個系統的架構可能是這樣的：
1、經由 APP 和 Web 的的請求，會經過 Nginx 均衡到多臺 Web 站點上去。
2、Web 集羣會調用並落地到 Service 集羣上
3、Service 集羣向數據層請求數據，正常情況下其中 90% 會落到 Cache 集羣中
4、Cache 集羣中不存在（假設 10%），會進入 DB 集羣去訪問數據庫。
我們通過壓測數據發現，web 層是瓶頸，tomcat 壓測單個實例只能支持 2500 的 QPS。
Cache 集羣和 DB 集羣足夠強悍，能夠輕鬆應對峯值 7500 的 QPS，按比例分別是 75000.9=6750 和 75000.1=750.
所以我們得到了 web 單實例極限的 QPS 是 2500。這邊需要下調，因爲我們不建議讓請求響應時長接近 2S，最好是 1S 以內。所以下調至 2000。
5、根據線上冗餘度最終確認
通過上面的計算，我們已經得到了峯值 QPS 是 7500，單個實例能夠順暢承載 QPS 是 2000，那麼 Web 集羣中至少有 4 個實例能夠承接這樣的請求洪峯。
除此之外，其他類型的的容量預估，如數據量、帶寬、CPU、MEMORY、DISK 等都可以採用類似策略。
案例分析
結合項目：如何計算圖書系統的 QPS、峯值 QPS、N 個實例和併發數
1、圖書預定系統的併發數計算：
1.1、二八法則定理：80% 的業務基本都是發生在 20% 的時間裏面，如系統有早中晚高峯，歷經 9 個小時（早上 10 點到晚上 19 點），9*3600=32400。
1.2、獲取峯值 QPS：公式：(總 PV 數 * 80%) / ( 每天秒數 * 20% ) = 峯值時間每秒請求數 (QPS)
即 (1500000 * 80%) / ( 32400 * 20% ) = 600000/6480≈185 / 秒
1.3、併發數 = QPS * 平均響應時間 = 0.5*185 = 92.5 ，矯正爲 100
1.4、利用 343 估算法判定 154，向上矯正爲 200
最後提供給性能測試 QA 的測試標準數據是 建議支持併發 200+，QA 最終的測試結果是 該併發下響應時間在 50~100ms
總結
系統設計容量評估時機：
1、臨時的流量變化：比如 618、雙 11，新年大促搞活動等場景，預估我們的流量會大漲，甚至到原來的數倍。這時候要做好應對的措施。
2、初始系統容量評估：假設我們開發了某個系統，這個系統初始上線，我們預估他的容量和負載會是多少。
3、容量基數的變化：比如某個系統，他的功能模塊越來越多，數據流量越來越大，日活指數越來越高，迎來了第二波的增長曲線。我們原來定好的系統容量漸漸的不滿足我們的需求，這時候我們也要重新評估和擴容。
系統設計容量評估的步驟：
1、分析日總訪問量：產品、運營的評估和線上數據的收集
2、評估日平均訪問量 QPS：評估運營時間內的平均 QPS
3、評估高峯區間的 QPS：流量曲線計算 或 28 法則估算
4、性能壓力測試：評估實例能夠承受的極限吞吐量
5、根據線上冗餘度，與實際的差值進行調整，評估出能承載容量的實際結果值
顯然，開頭的運動會如果子報名結束後能夠根據報名的人數對比，重新做容量設計，提早做好準備，情況就不會那麼糟糕。
作者：翁智華
來源：https://www.cnblogs.com/wzh2010/p/14454954.html
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/DTLImi47YUz9X0wF-mMpPA