先不考慮伺服器資源是否夠，瓶頸會首先出現在資料庫讀寫，假設現在有34W併發，而且根據訪問性質來看應該是報名操作，而報名操作是帶有資料庫CRUD的，Mysql的最大連線數是2000(假設沒做分庫分表，5W rmb讓開發商做分庫分表顯然是不可能的)，一般用到80%就很不錯了，所以連線數用1600來算。然後假設資料庫能在100ms內返回(想必也不是什麼好機器)，那麼一個連線1s能進行10次操作，那麼1600連線用滿，能進行1.6W次資料庫操作。

但這個也只是理論上的峰值，在實際專案中，單庫是絕達不到1.6W寫入的，並且還是涉及到多表操作的情況下。

實際上根據《高效能MySQL》第三版 1.5小節，在如下的測試環境中

測試機器Cisco UCSC250

記憶體384GB

儲存引擎是InnoDB

測試的資料集2.5GB

MySQL的buffer pool設定為4GB

所以在記憶體為384G的機器上，吞吐量不會超過8000。那麼384G機器要多少錢呢？

這是64G機器的價格，因此384=64*6 6*1.8W=10.8W/年

因此，如果要併發支援到8000，光資料庫就至少需要10W/Y。當然，這是假設請求在1s內返回的情況，假設我們允許服務能在5s內返回，那麼此時併發能支援到4W。還是在不考慮伺服器，網路損耗的情況下，實際上是遠遠達不到的。

所以，用5w來支援38w併發，是絕不可能的。

回到我們剛才的計算，假設資料庫吞吐量到達理論峰值，能支援8000使用者同時訪問，如果每個客戶能等待5s的化，能支援4w使用者(前提是這些使用者不可以同時訪問，需要在5s內做到均勻分佈，此時需要透過限流等手段來實現)

要支援8000使用者同時訪問，又需要多少個應用伺服器呢？

假設我們使用tomcat服務，每個執行緒所佔空間為8M，那麼光tomcat執行緒就需要: 8000*8=64000=64G，當然還需要有主機記憶體，損耗啥的，按照一倍計算就是128G，那麼需要是2*1.8W=3.6W

所以，如果需要支援4w個使用者5s延時的訪問，需要3.6+10.8= 14.4w rmb

這還只是伺服器的錢，不算開發成本在內

那麼，如果要支援38w的併發報名呢？這已經是一個相當大的併發量了，首先需要考慮的是拋棄掉一部分流量，可以在cdn就直接拋棄，或是nginx，或者直接在應用伺服器上，比如在這種情況下就只能保持8000/380000 = 2%，只能有2%的請求允許進來。

可以透過nginx+redis的方式拋棄掉98%的請求，這樣可以不用浪費應用伺服器資源。或者直接在應用伺服器上做操作，拋棄掉無法響應的請求，避免流量拖垮整個系統。