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

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

云服務(wù)器

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