鄒慶徵
3000人同時訪問一個純靜態文件，靜態文件大小28K，那瞬間請求流量最大理論值為：3000x28K≈82M 。但是此值僅僅是理論上的瞬間最大流量，因為你的站點不可能每時每秒都保持在3000人訪問，而是一段時間內的訪問人數。如果真是每秒都至少是3000人訪問，那你的服務器上行帶寬至少得在 82x8 = 656M（之所以乘以8，是因為我們說的速率和運營商說的速率不是一個概念，換算單位不同），這樣看來費用是相當的高。
但實際情況下並不能這樣計算，實際請求帶寬要遠遠低於656M，原因主要有以下幾點：
用戶流量是分散的，並不是每秒都有3000人訪問；
瀏覽器對於靜態頁是有緩存的，所以這3000人中有一部分用戶發出請求後，其實是直接從本地緩存中加載的，而沒有請求遠程服務器。
要知道，服務器的上行帶寬是很貴的，按上面計算方法，就算打個折，你的服務器固定帶寬100M的話，那光帶寬費用一個月就要近7000元。
所以一般中小型網站的服務器上行帶寬100M都算很大了，鑑於你的訪客量不固定，我給你的建議是：
前端走CDN緩存，如果靜態文件長期不更新，可以把緩存時間設得很長，如一個月；
後端ECS選擇低配即可，帶寬不要選固定帶寬（選擇按使用流量來計費，帶寬選擇5M足夠了）。
這種配置下，別說3000人同時訪問了，更高的併發都能抗得住。因為CDN本身就充當了負載均衡的角度，而且CDN節點遍佈全國，使得用戶“就近讀取”靜態資源。
以上就是我的觀點，對於這個問題大家是怎麼看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，歡迎關注我瞭解更多科技知識！
網絡圈
按照你給出的條件，css，視頻，圖片，樣式都外部存儲了，加上是靜態網頁，採用CDN+50M帶寬就足夠！利用CDN把靜態資源緩存起來，這樣 大大減輕了服務器的負擔！3000的併發還要考慮cpu，內存以及IO的開銷，不單單是考慮帶寬！
現在有好多做壓力測試的工具，做下壓力測試！
zhmn168
3000人同時訪問我的理解為併發訪問。首先這個要看你文件有多大，然後看用戶要在多少秒完加載完，假設你的文件大小是10K，用戶要在2秒內加載完，則下載速度的計算方法是： 10K * 3000 / 2 = 14.7M/s，需要14.7 * 8 = 117.6M帶寬。 請求包等額外信息，需要150M左右。
MoYangYang
最合適的是放到oos上，再加上cdn
