如何用5W rmb支持34W併發

在《這垃圾APP，差點毀了70萬高考生》一文中，咱們的報考app是用5W rmb 向供應商採購。在報名當天涌入海量考生，併發數飆升至34W，致使系統宕機，拒絕服務，致使考生沒法報名，輿情譁然。

那麼5W rmb 可否支持34W併發呢？

先不考慮服務器資源是否夠，瓶頸會首先出如今數據庫讀寫，假設如今有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=646 61.8W=10.8W/年

所以，若是要併發支持到8000，光數據庫就至少須要10W/Y。固然，這是假設請求在1s內返回的狀況，假設咱們容許服務能在5s內返回，那麼此時併發能支持到4W。仍是在不考慮服務器，網絡損耗的狀況下，其實是遠遠達不到的。

因此，用5w來支持38w併發，是毫不可能的。

回到咱們剛纔的計算，假設數據庫吞吐量到達理論峯值，能支持8000用戶同時訪問，若是每一個客戶能等待5s的化，能支持4w用戶(前提是這些用戶不能夠同時訪問，須要在5s內作到均勻分佈，此時須要經過限流等手段來實現)

要支持8000用戶同時訪問，又須要多少個應用服務器呢？

假設咱們使用tomcat服務，每一個線程所佔空間爲8M，那麼光tomcat線程就須要: 80008=64000=64G，固然還須要有主機內存，損耗啥的，按照一倍計算就是128G，那麼須要是21.8W=3.6W

因此，若是須要支持4w個用戶5s延時的訪問，須要3.6+10.8= 14.4w rmb

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

那麼，若是要支持38w的併發報名呢？這已是一個至關大的併發量了，首先須要考慮的是拋棄掉一部分流量，能夠在cdn就直接拋棄，或是nginx，或者直接在應用服務器上，好比在這種狀況下就只能保持8000/380000 = 2%，只能有2%的請求容許進來。

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