抗住春晚高并發(fā)的幕后英雄——云計算

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

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

云服務(wù)器

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