想上春晚發(fā)紅包，產(chǎn)品日活先過億。道理很簡單，用戶量低了，技術上很難支撐起春晚級別的高并發(fā)流量。

歷屆春晚紅包合作伙伴或多或少都有意外發(fā)生，有服務器宕機一小時的，有用戶臨時登錄不了的，有提現(xiàn)系統(tǒng)崩潰的，還有拖垮應用商店的。春晚紅包互動是全方位保障體系，技術能力、運營商、應用市場，甚至電力單位，一個環(huán)節(jié)出錯，整體活動就會受影響。

云服務器

面對數(shù)萬每秒的高并發(fā)功能，如果Web系統(tǒng)不做針對性的優(yōu)化，會輕而易舉地陷入到異常狀態(tài)。現(xiàn)在我們一起來討論下，大規(guī)模并發(fā)帶來的挑戰(zhàn)。 
1. 請求接口的合理設計
一個秒殺或者搶購頁面，通常分為2個部分，一個是靜態(tài)的HTML等內容，另一個就是參與秒殺的Web后臺請求接口。
通常靜態(tài)HTML等內容，是通過CDN的部署，一般壓力不大，核心瓶頸實際上在后臺請求接口上。這個后端接口，必須能夠支持高并發(fā)請求，同時，非常重要的一點，必須盡可能“快”，在最短的時間里返回用戶的請求結果。為了實現(xiàn)盡可能快這一點，接口的后端存儲使用內存級別的操作會更好一點。仍然直接面向MySQL之類的存儲是不合適的，如果有這種復雜業(yè)務的需求，都建議采用異步寫入。
當然，也有一些秒殺和搶購采用“滯后反饋”，就是說秒殺當下不知道結果，一段時間后才可以從頁面中看到用戶是否秒殺成功。但是，這種屬于“偷懶”行為，同時給用戶的體驗也不好，容易被用戶認為是“暗箱操作”。
2. 高并發(fā)的挑戰(zhàn)：一定要“快”
我們通常衡量一個Web系統(tǒng)的吞吐率的指標是QPS（Query Per Second，每秒處理請求數(shù)），解決每秒數(shù)萬次的高并發(fā)場景，這個指標非常關鍵。舉個例子，我們假設處理一個業(yè)務請求平均響應時間為100ms，同時，系統(tǒng)內有20臺Apache的Web服務器，配置MaxClients為500個（表示Apache的最大連接數(shù)目）。
那么，我們的Web系統(tǒng)的理論峰值QPS為（理想化的計算方式）：
20*500/0.1 = 100000 （10萬QPS）
咦？我們的系統(tǒng)似乎很強大，1秒鐘可以處理完10萬的請求，5w/s的秒殺似乎是“紙老虎”。實際情況，當然沒有這么理想。在高并發(fā)的實際場景下，機器都處于高負載的狀態(tài)，在這個時候平均響應時間會被大大增加。
就Web服務器而言，Apache打開了越多的連接進程，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗，然后就直接導致平均響應時間增加。因此上述的MaxClient數(shù)目，要根據(jù)CPU、內存等硬件因素綜合考慮，絕對不是越多越好?？梢酝ㄟ^Apache自帶的abench來測試一下，取一個合適的值。然后，我們選擇內存操作級別的存儲的Redis，在高并發(fā)的狀態(tài)下，存儲的響應時間至關重要。網(wǎng)絡帶寬雖然也是一個因素，不過，這種請求數(shù)據(jù)包一般比較小，一般很少成為請求的瓶頸。負載均衡成為系統(tǒng)瓶頸的情況比較少，在這里不做討論。
那么問題來了，假設我們的系統(tǒng)，在5w/s的高并發(fā)狀態(tài)下，平均響應時間從100ms變?yōu)?50ms（實際情況，甚至更多）：
20*500/0.25 = 40000 （4萬QPS）
于是，我們的系統(tǒng)剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。
然后，這才是真正的惡夢開始。舉個例子，高速路口，1秒鐘來5部車，每秒通過5部車，高速路口運作正常。突然，這個路口1秒鐘只能通過4部車，車流量仍然依舊，結果必定出現(xiàn)大塞車。（5條車道忽然變成4條車道的感覺）
同理，某一個秒內，20*500個可用連接進程都在滿負荷工作中，卻仍然有1萬個新來請求，沒有連接進程可用，系統(tǒng)陷入到異常狀態(tài)也是預期之內。
其實在正常的非高并發(fā)的業(yè)務場景中，也有類似的情況出現(xiàn)，某個業(yè)務請求接口出現(xiàn)問題，響應時間極慢，將整個Web請求響應時間拉得很長，逐漸將Web服務器的可用連接數(shù)占滿，其他正常的業(yè)務請求，無連接進程可用。
更可怕的問題是，是用戶的行為特點，系統(tǒng)越是不可用，用戶的點擊越頻繁，惡性循環(huán)最終導致“雪崩”（其中一臺Web機器掛了，導致流量分散到其他正常工作的機器上，再導致正常的機器也掛，然后惡性循環(huán)），將整個Web系統(tǒng)拖垮。
3. 重啟與過載保護
如果系統(tǒng)發(fā)生“雪崩”，貿然重啟服務，是無法解決問題的。最常見的現(xiàn)象是，啟動起來后，立刻掛掉。這個時候，最好在入口層將流量拒絕，然后再將重啟。如果是redis/memcache這種服務也掛了，重啟的時候需要注意“預熱”，并且很可能需要比較長的時間。
秒殺和搶購的場景，流量往往是超乎我們系統(tǒng)的準備和想象的。這個時候，過載保護是必要的。如果檢測到系統(tǒng)滿負載狀態(tài)，拒絕請求也是一種保護措施。在前端設置過濾是最簡單的方式，但是，這種做法是被用戶“千夫所指”的行為。更合適一點的是，將過載保護設置在CGI入口層，快速將客戶的直接請求返回。
互聯(lián)網(wǎng)正在高速發(fā)展，使用互聯(lián)網(wǎng)服務的用戶越多，高并發(fā)的場景也變得越來越多。電商秒殺和搶購，是兩個比較典型的互聯(lián)網(wǎng)高并發(fā)場景。雖然我們解決問題的具體技術方案可能千差萬別，但是遇到的挑戰(zhàn)卻是相似的，因此解決問題的思路也異曲同工。
在此基礎上，新網(wǎng)云通過流量分發(fā)擴展應用系統(tǒng)對外的服務能力，提高應用程序的容錯能力，為企業(yè)提供容災、備份、恢復、遷移等方面的全套解決方案，徹底解決應用的煩惱，全方位有效規(guī)避應用、系統(tǒng)、數(shù)據(jù)的安全風險：http://www.xinnet.com/cs/product.html