服務(wù)器高并發(fā)(一)
- 作者:新網(wǎng)
- 來(lái)源:新網(wǎng)
- 瀏覽:100
- 2018-05-10 17:53:06
在網(wǎng)上購(gòu)物秒搶某個(gè)商品,比如說(shuō)小米手機(jī),這對(duì)我們來(lái)說(shuō)都不陌生。這些看似很簡(jiǎn)單的東西從技術(shù)的角度來(lái)說(shuō)對(duì)于Web系統(tǒng)是一個(gè)巨大的考驗(yàn),一個(gè)Web系統(tǒng)在很短時(shí)間內(nèi)收到很多請(qǐng)求時(shí),系統(tǒng)的優(yōu)化和穩(wěn)定至關(guān)重要。今天就由小編為大家詳細(xì)解釋一下這些問(wèn)題。
在網(wǎng)上購(gòu)物秒搶某個(gè)商品,比如說(shuō)小米手機(jī),這對(duì)我們來(lái)說(shuō)都不陌生。這些看似很簡(jiǎn)單的東西從技術(shù)的角度來(lái)說(shuō)對(duì)于Web系統(tǒng)是一個(gè)巨大的考驗(yàn),一個(gè)Web系統(tǒng)在很短時(shí)間內(nèi)收到很多請(qǐng)求時(shí),系統(tǒng)的優(yōu)化和穩(wěn)定至關(guān)重要。今天就由小編為大家詳細(xì)解釋一下這些問(wèn)題。
<
div>
1、大規(guī)模并發(fā)帶來(lái)的挑戰(zhàn)
比如說(shuō)5w每秒的高并發(fā)秒殺功能,在這個(gè)過(guò)程中,整個(gè)Web系統(tǒng)遇到了很多的問(wèn)題和挑戰(zhàn)。如果Web系統(tǒng)不做針對(duì)性的優(yōu)化,會(huì)輕而易舉地陷入到異常狀態(tài)。一起來(lái)討論下優(yōu)化的思路和方法。
1.1、請(qǐng)求接口的合理設(shè)計(jì)
一個(gè)搶購(gòu)頁(yè)面,通常分為2個(gè)部分,一個(gè)是靜態(tài)的HTML等內(nèi)容,另一個(gè)就是Web后臺(tái)請(qǐng)求接口。通常靜態(tài)HTML等內(nèi)容,是通過(guò)CDN的部署,一般壓力不大,核心瓶頸實(shí)際上在后臺(tái)請(qǐng)求接口上。這個(gè)后端接口,必須能夠支持高并發(fā)請(qǐng)求,同時(shí)必須盡可能“快”,在最短的時(shí)間里返回用戶的請(qǐng)求結(jié)果。為了實(shí)現(xiàn)盡可能快這一點(diǎn),接口的后端存儲(chǔ)使用內(nèi)存級(jí)別的操作會(huì)更好一點(diǎn),仍然直接面向MySQL之類(lèi)
數(shù)據(jù)庫(kù)的存儲(chǔ)是不合適的,如果有這種復(fù)雜業(yè)務(wù)的需求,都建議采用異步寫(xiě)入。
1.2、高并發(fā)的挑戰(zhàn)
衡量一個(gè)Web系統(tǒng)的吞吐率的指標(biāo)是QPS(Query Per Second,每秒處理請(qǐng)求數(shù)),解決每秒數(shù)萬(wàn)次的高并發(fā)場(chǎng)景,這個(gè)指標(biāo)非常關(guān)鍵。假設(shè)處理一個(gè)業(yè)務(wù)請(qǐng)求平均響應(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萬(wàn)QPS) ,系統(tǒng)似乎很強(qiáng)大,1秒鐘可以處理完10萬(wàn)的請(qǐng)求,實(shí)際情況當(dāng)然沒(méi)有這么理想。在高并發(fā)的實(shí)際場(chǎng)景下,機(jī)器都處于高負(fù)載的狀態(tài),在這個(gè)時(shí)候平均響應(yīng)時(shí)間會(huì)被大大增加。就Web服務(wù)器而言,Apache打開(kāi)了越多的連接進(jìn)程,CPU需要處理的上下文切換也越多,額外增加了CPU的消耗,然后就直接導(dǎo)致平均響應(yīng)時(shí)間增加。因此上述的MaxClient數(shù)目,要根據(jù)CPU、內(nèi)存等硬件因素綜合考慮,絕對(duì)不是越多越好。可以通過(guò)Apache自帶的abench來(lái)測(cè)試一下,取一個(gè)合適的值。然后,我們選擇內(nèi)存操作級(jí)別的存儲(chǔ)的Redis,在高并發(fā)的狀態(tài)下,存儲(chǔ)的響應(yīng)時(shí)間至關(guān)重要,不考慮網(wǎng)絡(luò)帶寬和
負(fù)載均衡問(wèn)題。假設(shè)系統(tǒng),在5w/s的高并發(fā)狀態(tài)下,平均響應(yīng)時(shí)間從100ms變?yōu)?50ms(實(shí)際情況,甚至更多):20*500/0.25 = 40000 (4萬(wàn)QPS)于是系統(tǒng)剩下了4w的QPS,面對(duì)5w每秒的請(qǐng)求,中間相差了1w。 舉個(gè)通俗例子說(shuō)明,收費(fèi)站1秒鐘來(lái)5部車(chē),每秒通過(guò)5部車(chē),收費(fèi)站運(yùn)作正常。突然這個(gè)收費(fèi)站1秒鐘只能通過(guò)4部車(chē),車(chē)流量仍然依舊,結(jié)果必定出現(xiàn)大塞車(chē)。(5條車(chē)道忽然變成4條車(chē)道的感覺(jué))同理某一個(gè)秒內(nèi),20*500個(gè)可用連接進(jìn)程都在滿負(fù)荷工作中,卻仍然有1萬(wàn)個(gè)新來(lái)請(qǐng)求,沒(méi)有連接進(jìn)程可用,系統(tǒng)陷入到異常狀態(tài)也是預(yù)期之內(nèi)。其實(shí)在正常的非高并發(fā)的業(yè)務(wù)場(chǎng)景中,也有類(lèi)似的情況出現(xiàn),某個(gè)業(yè)務(wù)請(qǐng)求接口出現(xiàn)問(wèn)題,響應(yīng)時(shí)間極慢,將整個(gè)Web請(qǐng)求響應(yīng)時(shí)間拉得很長(zhǎng),逐漸將Web服務(wù)器的可用連接數(shù)占滿,影響其他正常的業(yè)務(wù)請(qǐng)求,無(wú)連接進(jìn)程可用。更嚴(yá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)拖垮。
1.3、重啟與過(guò)載保護(hù)
如果系統(tǒng)發(fā)生“雪崩”,貿(mào)然重啟服務(wù),是無(wú)法解決問(wèn)題的。這種情況最好在入口層將流量拒絕,然后再將重啟,如果是redis/memcache這種服務(wù)也掛了,重啟的時(shí)候需要注意“預(yù)熱”,并且很可能需要比較長(zhǎng)的時(shí)間。秒殺和搶購(gòu)的場(chǎng)景,流量往往是超乎系統(tǒng)的準(zhǔn)備和想象的。這個(gè)時(shí)候過(guò)載保護(hù)是必要的。如果檢測(cè)到系統(tǒng)滿負(fù)載狀態(tài),拒絕請(qǐng)求也是一種保護(hù)措施。在前端設(shè)置過(guò)濾是最簡(jiǎn)單的方式,但是,這種做法是會(huì)被客戶罵的,更合適的
解決方案是將過(guò)載保護(hù)設(shè)置在CGI入口層,快速將客戶的直接請(qǐng)求返回。