低調的牛肉
作為開發/架構，經常會被問到這樣的問題：
“這個產品（功能）上線後，預計會有大量的用戶進來，你們系統能不能扛得住”；
“馬上就要到業務節點了，你們系統用不用加一些資源”；
這些問題都涉及到了流量評估和容量設計，我分享一下我經常用的一些方法，當然項目的流量和互聯網公司沒法比，大家也別見笑。
先算總訪問量
也就是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開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
