先不考慮服務(wù)器資源是否夠，瓶頸會(huì)首先出現(xiàn)在數(shù)據(jù)庫(kù)讀寫，假設(shè)現(xiàn)在有34W并發(fā)，而且根據(jù)訪問(wèn)性質(zhì)來(lái)看應(yīng)該是報(bào)名操作，而報(bào)名操作是帶有數(shù)據(jù)庫(kù)CRUD的，Mysql的最大連接數(shù)是2000(假設(shè)沒(méi)做分庫(kù)分表，5W rmb讓開(kāi)發(fā)商做分庫(kù)分表顯然是不可能的)，一般用到80%就很不錯(cuò)了，所以連接數(shù)用1600來(lái)算。然后假設(shè)數(shù)據(jù)庫(kù)能在100ms內(nèi)返回(想必也不是什么好機(jī)器)，那么一個(gè)連接1s能進(jìn)行10次操作，那么1600連接用滿，能進(jìn)行1.6W次數(shù)據(jù)庫(kù)操作。

但這個(gè)也只是理論上的峰值，在實(shí)際項(xiàng)目中，單庫(kù)是絕達(dá)不到1.6W寫入的，并且還是涉及到多表操作的情況下。

實(shí)際上根據(jù)《高性能MySQL》第三版 1.5小節(jié)，在如下的測(cè)試環(huán)境中

測(cè)試機(jī)器Cisco UCSC250

內(nèi)存384GB

存儲(chǔ)引擎是InnoDB

測(cè)試的數(shù)據(jù)集2.5GB

MySQL的buffer pool設(shè)置為4GB

所以在內(nèi)存為384G的機(jī)器上，吞吐量不會(huì)超過(guò)8000。那么384G機(jī)器要多少錢呢？

這是64G機(jī)器的價(jià)格，因此384=64*6 6*1.8W=10.8W/年

因此，如果要并發(fā)支持到8000，光數(shù)據(jù)庫(kù)就至少需要10W/Y。當(dāng)然，這是假設(shè)請(qǐng)求在1s內(nèi)返回的情況，假設(shè)我們?cè)试S服務(wù)能在5s內(nèi)返回，那么此時(shí)并發(fā)能支持到4W。還是在不考慮服務(wù)器，網(wǎng)絡(luò)損耗的情況下，實(shí)際上是遠(yuǎn)遠(yuǎn)達(dá)不到的。

所以，用5w來(lái)支持38w并發(fā)，是絕不可能的。

回到我們剛才的計(jì)算，假設(shè)數(shù)據(jù)庫(kù)吞吐量到達(dá)理論峰值，能支持8000用戶同時(shí)訪問(wèn)，如果每個(gè)客戶能等待5s的化，能支持4w用戶(前提是這些用戶不可以同時(shí)訪問(wèn)，需要在5s內(nèi)做到均勻分布，此時(shí)需要通過(guò)限流等手段來(lái)實(shí)現(xiàn))

要支持8000用戶同時(shí)訪問(wèn)，又需要多少個(gè)應(yīng)用服務(wù)器呢？

假設(shè)我們使用tomcat服務(wù)，每個(gè)線程所占空間為8M，那么光tomcat線程就需要: 8000*8=64000=64G，當(dāng)然還需要有主機(jī)內(nèi)存，損耗啥的，按照一倍計(jì)算就是128G，那么需要是2*1.8W=3.6W

所以，如果需要支持4w個(gè)用戶5s延時(shí)的訪問(wèn)，需要3.6+10.8= 14.4w rmb

這還只是服務(wù)器的錢，不算開(kāi)發(fā)成本在內(nèi)

那么，如果要支持38w的并發(fā)報(bào)名呢？這已經(jīng)是一個(gè)相當(dāng)大的并發(fā)量了，首先需要考慮的是拋棄掉一部分流量，可以在cdn就直接拋棄，或是nginx，或者直接在應(yīng)用服務(wù)器上，比如在這種情況下就只能保持8000/380000 = 2%，只能有2%的請(qǐng)求允許進(jìn)來(lái)。

可以通過(guò)nginx+redis的方式拋棄掉98%的請(qǐng)求，這樣可以不用浪費(fèi)應(yīng)用服務(wù)器資源。或者直接在應(yīng)用服務(wù)器上做操作，拋棄掉無(wú)法響應(yīng)的請(qǐng)求，避免流量拖垮整個(gè)系統(tǒng)。