前幾天聊過，pv 和併發 的概念，也大概解釋了 併發，帶寬等指標的計算。感興趣的朋友，可以看看我前面那篇文章：《聊一聊PV和併發》。今天再來聊一聊容量預估。
電商公司的朋友，，這樣的場景是否似曾相識：
運營和產品神秘兮兮的跑過來問：
我們晚上要做搞個促銷，服務器能抗住麼？如果扛不住，需要加多少臺機器？
於是，技術一臉懵逼。
其實，這些都是系統容量預估的問題，容量預估是架構師必備的技能之一。所謂，容量預估其實說白了就是，系統在down掉之前，所能承受的最大流量。這個事技術人員對於系統性能瞭解的重要指標。常見的容量評估包括流量、併發量、帶寬、CPU,內存 ,磁盤等一系列內容。今天就來聊一聊容量預估的問題。
一，幾個重要參數
QPS：每秒鐘處理的請求數
併發量： 系統同時處理的請求數
響應時間： 一般取平均響應時間
很多人經常會把併發數和QPS 混淆，理解了上面三個要素的意義之後，就能推算出它們之間的關係：QPS = 併發量 / 平均響應時間。
二，容量評估的步驟與方法
1：預估總訪問量
如何知道總訪問量？對於一個運營活動的訪問量評估，或者一個系統上線後PV的評估，有什麼好的方法？
最簡單的辦法就是：詢問業務方，詢問運營同學，詢問產品同學，看產品和運營對此次活動的流量預估。
不過，業務方對於流量的預估，應該就兩個指標，pv 和 用戶訪問數。技術人員 需要更具這兩個數據，計算其他相關指標，比如 QPS 等。具體如何計算可參照我前面一篇 pv和併發 的文章。
2：預估平均QPS
總請求數 = 總PV * 頁面衍生連接數
平均QPS = 總請求數 / 總時間
比如：活動落地頁1小時內的總訪問量是30w pv，該落地頁的衍生連接數為30，那麼落地頁的平均QPS
30w * 30) /(60 * 60) = 2500，
3：預估峰值QPS
系統容量規劃時，不能只考慮平均QPS，而是要抗住高峰的QPS，如何評估峰值QPS呢？
這個要根據實際的業務評估，通過以往的一些營銷活動的 pv 等數據進行預估。一般情況，峰值QPS大概是均值QPS的3-5倍，日均QPS為1000，於是評估出峰值QPS為5000。
不過，有一些業務例如“秒殺業務”比較難評估業務訪問量，這類業務的容量評估不在此討論。
4：預估系統、單機極限QPS
如何預估一個業務，一個服務器單機的極限QPS呢？
這個性能指標，是服務器，最基本的指標之一，所以沒有其他的辦法，就是壓力測試。通過壓力測試，算出服務器的單機極限QPS 。
在一個業務上線前，一般都需要進行壓力測試（很多創業型公司，業務迭代很快的系統可能沒有這一步，那就悲劇了），以APP 推送 某營銷活動為例（預計 日均QPS 1000，峰值QPS 5000），業務場景可能是這樣的：
1）通過 APP 推送一個活動消息
2）運營活動H5落地頁是一個web站點
3）H5落地頁由緩存cache、數據庫db中的數據拼裝而成
通過壓力測試發現，web 服務器 單機只能抗住1200的QPS，cache和數據庫db 能抗住併發壓力，（一般來說，1%的流量到數據庫，數據庫120 QPS還是能輕鬆抗住的，cache的話QPS能抗住，需要評估cache的帶寬，這裡假設cache不是瓶頸），這樣，我們就得到了web單機極限的QPS是1200。一般來說，生產系統不會跑滿到極限的，這樣容易影響服務器的壽命和性能，單機線上允許跑到QPS 1200 * 0.8 = 960 。
擴展說一句，通過壓力測試，已經知道web層是瓶頸，則可針對web 相關的做一些調整優化，以提高web 服務器 的單機QPS 。
還有，壓力測試工作中，一般是以具體業務的角度進行壓力測試，關心的是某個具體業務的併發量和QPS。
5：回答最開始那兩個問題
需要的機器 = 峰值QPS / 單機極限 QPS
好了，上述已經得到了峰值QPS是5000，單機極限QPS是1000，線上部署了3臺服務器：
（1）服務器能抗住麼？ -> 峰值5000，單機1000，線上3臺，扛不住
（2）如果扛不住，需要加多少臺機器？ -> 需要額外2臺，提前預留1臺更好，給3臺保險
三，最後
需要注意的是，以上都是計算單個服務器或是單個集群的容量，實際生產環境是由web, 消息隊列，緩存，數據庫 等等一系列組成的複雜集群。在分佈式系統中，任何節點出現瓶頸，都有可能導致雪崩效應，最後整個集群垮掉 （“雪崩效應”指的是系統中一個小問題會逐漸擴大，最後造成整個集群宕機）。所以，要了解規劃整個平臺的容量，就必須計算出每一個節點的容量。找出任何可能出現的瓶頸所在。
以上，只是個人一些經驗分享，有啥不對的地方，大夥輕點拍磚，有更好的建議歡迎回復。
閱讀更多 章為忠學架構 的文章
