網際網路公司，這樣的場景是否似曾相識：
場景一：pm要做乙個很大的運營活動，技術老大殺過來，問了兩個問題：
（1）機器能抗住麼？
（2）如果扛不住，需要加多少臺機器？
場景二：系統設計階段，技術老大殺過來，又問了兩個問題：
（1）資料庫需要分庫麼？
（2）如果需要分庫，需要分幾個庫？
技術上來說，這些都是系統容量預估的問題，容量設計是架構師必備的技能之一。常見的容量評估包括資料量、併發量、頻寬、cpu/mem/disk等，今天分享的內容，就以【併發量】為例，看看如何回答好這兩個問題。
【步驟一：評估總訪問量】
如何知道總訪問量？對於乙個運營活動的訪問量評估，或者乙個系統上線後pv的評估，有什麼好的方法？
答案是：詢問業務方，詢問運營同學，詢問產品同學，看對運營活動或者產品上線後的預期是什麼。
回答：5000w*10% = 500w
【步驟二：評估平均訪問量qps】
如何知道平均訪問量qps？
答案是：有了總量，除以總時間即可，如果按照天評估，一天按照4w秒計算。
舉例1：push落地頁系統30分鐘的總訪問量是500w，求平均訪問量qps
回答：500w/(30*60) = 2778，大概3000qps
舉例2：主站首頁估計日均pv 8000w，求平均訪問qps
回答：一天按照4w秒算，8000w/4w=2000，大概2000qps
提問：為什麼一天按照4w秒計算？
回答：一天共24小時*60分鐘*60秒=8w秒，一般假設所有請求都發生在白天，所以一般來說一天只按照4w秒評估
【步驟三：評估高峰qps】
系統容量規劃時，不能只考慮平均qps，而是要抗住高峰的qps，如何知道高峰qps呢？
答案是：根據業務特性，通過業務訪問曲線評估
【步驟四：評估系統、單機極限qps】
如何評估乙個業務，乙個服務單機能的極限qps呢？
答案是：壓力測試
2）運營活動h5落地頁是乙個web站點
3）h5落地頁由快取cache、資料庫db中的資料拼裝而成
通過壓力測試發現，web層是瓶頸，tomcat壓測單機只能抗住1200的qps（一般來說，1%的流量到資料庫，資料庫500qps還是能輕鬆抗住的，cache的話qps能抗住，需要評估cache的頻寬，假設不是瓶頸），我們就得到了web單機極限的qps是1200。一般來說，線上系統是不會跑滿到極限的，打個8折，單機線上允許跑到qps1000。
【步驟五：根據線上冗餘度回答兩個問題】
好了，上述步驟1-4已經得到了峰值qps是5000，單機qps是1000，假設線上部署了2臺服務，就能自信自如的回答技術老大提出的問題了：
（1）機器能抗住麼？ -> 峰值5000，單機1000，線上2臺，扛不住
（2）如果扛不住，需要加多少臺機器？ -> 需要額外3臺，提前預留1臺更好，給4臺更穩
除了併發量的容量預估，資料量、頻寬、cpu/mem/disk等評估亦可遵循類似的步驟。
網際網路架構設計如何進行容量評估：
【步驟一：評估總訪問量】-> 詢問業務、產品、運營
【步驟二：評估平均訪問量qps】-> 除以時間，一天算4w秒
【步驟三：評估高峰qps】-> 根據業務曲線圖來
【步驟四：評估系統、單機極限qps】-> 壓測很重要
【步驟五：根據線上冗餘度回答兩個問題】-> 估計冗餘度與線上冗餘度差值
網際網路架構
網際網路架構，主要追求的是高可用，可擴充套件 這兩個特性 在這裡做了一些個人的總結，算是給2014年的工作做個總結。推陳出新 一定要做的，死守積累會逐漸丟失人才，但凡技術公司都會不斷更新技術 kiss原則 keep it stupid優秀的 都會很簡單，簡單理解，簡單更改，能把複雜的事情做簡單是一種...
網際網路架構
使用者在同一時間內大量的訪問伺服器，tomcat伺服器併發能力為 200 250左右 jvm調優為1000 硬體條件 物理伺服器處理能力 網路頻寬 2.1 分布式計算 由多個執行緒，共同來完成某項特定的任務，拆合問題 2.2 分布式系統 distributed system 是建立在網路之上的軟體系...
網際網路軟體架構，該怎麼進行容量規劃
三，總結 在競爭激烈的電商公司中，會經常有這樣的業務場景 場景一 市場部策劃要做乙個很大的運營活動，技術負責人衝過來，拋下兩個問題 1 伺服器效能怎樣，是否能抗住麼？2 如果扛不住，需要加多少伺服器？場景二 系統設計階段，技術負責人衝過來，又問了兩個問題 1 資料庫需要分庫分表麼？2 如果需要分庫分...