電商系列(六)以電商系統為例,聊一聊系統容量預估

前幾天聊過,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, 消息隊列,緩存,數據庫 等等一系列組成的複雜集群。在分佈式系統中,任何節點出現瓶頸,都有可能導致雪崩效應,最後整個集群垮掉 (“雪崩效應”指的是系統中一個小問題會逐漸擴大,最後造成整個集群宕機)。所以,要了解規劃整個平臺的容量,就必須計算出每一個節點的容量。找出任何可能出現的瓶頸所在。

以上,只是個人一些經驗分享,有啥不對的地方,大夥輕點拍磚,有更好的建議歡迎回復。



分享到:


相關文章: