架構，如何進行容量設計？
互聯網公司，這樣的場景是否似曾相識？web
場景一
pm要作雙十一促銷活動，技術老大殺過來，問了兩個問題：面試
- 機器能抗住麼？
- 若是扛不住，須要加多少臺機器？
場景二
新系統上線，技術老大殺過來，又問：數據庫
- 數據庫須要分庫麼？
- 若是須要分庫，須要分幾個庫？
技術上來講，這些都是系統容量預估的問題，容量設計是架構師必備的技能。緩存
常見的容量評估包括數據量、併發量、帶寬、CPU/MEM/DISK等，今天分享的內容，就以併發量爲例，看看如何經過五個步驟，獲得問題的答案。tomcat
步驟一：評估總訪問量
如何知道總訪問量？架構
對於一個運營活動的訪問量評估，或者一個系統上線後PV的評估，有什麼好的方法？
答：
詢問運營同窗，活動的預期訪問是什麼；
詢問產品同窗，產品上線後的預期訪問是什麼。併發
栗子：
假設，58同城要作一個APP-push的運營活動，計劃在30分鐘內完成5000w用戶的push推送，預計push消息點擊率10%，如何評估push落地頁系統的總訪問量？
答：5000w*10% = 500wide
步驟二：評估平均訪問量QPS
如何知道平均訪問量QPS？
答：總量除以總時間便可，若是按照天評估，一天按照4w秒計算。
畫外音：一天86400秒，通常認爲請求發生在白天，即4w秒。測試
栗子：
push落地頁系統30分鐘的總訪問量是500w，求平均訪問QPS？
答：500w/(30*60) = 2778，大概3000QPS。架構設計
栗子：
假設，58同城主站首頁估計日均pv 8000w，求平均訪問QPS？
答：一天按照4w秒算，8000w/4w=2000，大概2000QPS。
步驟三：評估高峯QPS
系統容量規劃時，不能只考慮平均QPS，而是要抗住高峯的QPS，如何知道高峯QPS呢？
答：根據業務特性，經過業務訪問曲線評估。
栗子：
假設，某業務日均QPS爲2000，業務訪問趨勢圖以下圖，求峯值QPS預估？
答：從圖中能夠看出，峯值QPS大概是均值QPS的2.5倍，日均QPS爲2000，因而評估出峯值QPS爲5000。
畫外音：有一些業務例如「秒殺業務」比較難畫出業務訪問趨勢圖，這類業務的容量評估不在此列。
步驟四：評估系統、單機極限QPS
如何評估一個業務，一個服務單機能的極限QPS呢？
答：壓力測試。
在一個服務上線前，通常來講是須要進行壓力測試，以APP-push運營活動落地頁爲例（日均QPS2000，峯值QPS5000），這個系統的架構多是這樣的：
- 訪問端是APP
- 運營活動H5落地頁是一個web站點
- H5落地頁由緩存cache、數據庫db中的數據拼裝而成
經過壓力測試發現，web層是瓶頸，tomcat壓測單機只能抗住1200的QPS。
畫外音：通常來講，1%的流量到數據庫，數據庫500QPS仍是能輕鬆抗住的，cache的話QPS能抗住，須要評估cache的帶寬，假設不是瓶頸。
咱們就獲得了web單機極限的QPS是1200，通常線上系統是不會跑滿，打個8折，單機線上容許跑到QPS1000。
步驟五：根據線上冗餘度解題
好了，上述步驟1-4已經獲得了峯值QPS是5000，單機QPS是1000，假設線上部署了2臺服務，就能自信自如的回答技術老大提出的問題了。
技術老大問：機器能抗住麼？
答：峯值5000，單機1000，線上2臺，扛不住。
若是扛不住，須要加多少臺機器？
答：須要額外3臺，給4臺更穩。
除了併發量的容量預估，數據量、帶寬、CPU/MEM/DISK等評估亦可遵循相似的步驟。
總結
互聯網架構設計如何進行容量評估：
一，評估總訪問量：詢問產品、運營；
二，評估平均訪問量：總量除以總時間，一天算4w秒；
三，評估高峯QPS：根據業務曲線圖來；
四，評估系統、單機極限QPS：壓測很重要；
五：根據線上冗餘度解題：估計冗餘度與線上冗餘度差值；
但願你們有收穫。
架構師之路-分享可落地的技術文章
推薦閱讀：《拜託，面試別再問我基數排序了！》《拜託，面試別再問我計數排序了！》《拜託，面試別再問我桶排序了！》