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

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

云服務器

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