常見的容量評估包括數據量、併發量、帶寬、CPU/MEM/DISK等,今天分享的內容,就以併發量為例,看看如何通過五個步驟,得到問題的答案。
互聯網公司,這樣的場景是否似曾相識?
場景一
pm要做雙十一促銷活動,技術老大殺過來,問了兩個問題:
- 機器能抗住麼?
- 如果扛不住,需要加多少臺機器?
場景二
新系統上線,技術老大殺過來,又問:
- 數據庫需要分庫麼?
- 如果需要分庫,需要分幾個庫?
技術上來說,這些都是系統容量預估的問題,容量設計是架構師必備的技能。
常見的容量評估包括數據量、併發量、帶寬、CPU/MEM/DISK等,今天分享的內容,就以併發量為例,看看如何通過五個步驟,得到問題的答案。
步驟一:評估總訪問量
如何知道總訪問量?
對於一個運營活動的訪問量評估,或者一個系統上線後PV的評估,有什麼好的方法?
答:
詢問運營同學,活動的預期訪問是什麼;
詢問產品同學,產品上線後的預期訪問是什麼。
栗子:
假設,58同城要做一個APP-push的運營活動,計劃在30分鐘內完成5000w用戶的push推送,預計push消息點擊率10%,如何評估push落地頁系統的總訪問量?
答:5000w*10% = 500w
步驟二:評估平均訪問量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:壓測很重要;
五:根據線上冗餘度解題:估計冗餘度與線上冗餘度差值;
希望大家有收穫。
閱讀更多 互聯網技術到家 的文章