低調的牛肉
作為開發/架構,經常會被問到這樣的問題:
“這個產品(功能)上線後,預計會有大量的用戶進來,你們系統能不能扛得住”;
“馬上就要到業務節點了,你們系統用不用加一些資源”;
這些問題都涉及到了流量評估和容量設計,我分享一下我經常用的一些方法,當然項目的流量和互聯網公司沒法比,大家也別見笑。
先算總訪問量
也就是PV,如果是網頁的話,打開一次網頁,這個網站的PV就增加了一次,如果是接口的話,就是接口的訪問次數。
訪問總量的預估,可以問業務/產品/運營的夥伴,這個產品(功能)上線後的預期是多少,或者用以往產品(功能)上線後的訪問量作參考,做一個預估。
比如我之前參與過的項目,每天要給過生日的用戶發送生日祝福短信,那麼就可以大概評估出每天這個功能的總量大約是:總客戶數量/365。
(圖為10%的數據採樣,相當於每天大約160萬的訪問量)
評估平均訪問量
TPS:是指每秒內的事務數,如果執行了DML操作,那麼相應的TPS會增加;
QPS:是指每秒內查詢次數,如果執行了select操作,相應的QPS會增加。
評估高峰期間的訪問量
在做流量評估和容量設計的時候,不能只考慮平均QPS,一定要考慮高峰的QPS,我們系統的容量,一定要能抗住高峰的QPS。
如果每天80%的訪問集中在30%的時間裡,這30%時間叫做峰值時間;那麼高峰期的訪問量=(總訪問量*80%)/(每天秒數*30%);
例如我們系統的訪問量,主要集中在9:30-11:30和13:30-17:30期間,大約有6個小時。
評估每臺機器的QPS,進而評估出需要多少服務器資源
通過壓力測試,評估出一臺服務單機能的極限QPS,比如單臺服務器QPS極限是500;
生產環境中預估高峰期間的訪問量是3000,那麼至少需要6臺服務器,當然當臺機器極限是500,我們可以按照400進行預估,那麼就需要8臺機器,當然為了保險期間,部署10臺是比較保險的(有一定的冗餘度)。
希望我的回答,能夠幫助到你!我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。