高并發(fā)級(jí)別簡(jiǎn)述

術(shù)語(yǔ)說(shuō)明：

QPS = req/sec = 請(qǐng)求數(shù)/秒

QPS: 每秒鐘處理完請(qǐng)求的次數(shù)；注意這里是處理完。具體是指發(fā)出請(qǐng)求到服務(wù)器處理完成功返回結(jié)果?？梢岳斫庠趕erver中有個(gè)counter，每處理一個(gè)請(qǐng)求加1，1秒后counter=QPS。

【QPS計(jì)算PV和機(jī)器的方式】

QPS統(tǒng)計(jì)方式 [一般使用 http_load 進(jìn)行統(tǒng)計(jì)]QPS = 總請(qǐng)求數(shù) / ( 進(jìn)程總數(shù) * 請(qǐng)求時(shí)間 )QPS: 單個(gè)進(jìn)程每秒請(qǐng)求服務(wù)器的成功次數(shù)

單臺(tái)服務(wù)器每天PV計(jì)算公式1：每天總PV = QPS * 3600 * 6公式2：每天總PV = QPS * 3600 * 8

服務(wù)器計(jì)算服務(wù)器數(shù)量 = ceil( 每天總PV / 單臺(tái)服務(wù)器每天總PV )

【峰值QPS和機(jī)器計(jì)算公式】

原理：每天80%的訪問(wèn)集中在20%的時(shí)間里，這20%時(shí)間叫做峰值時(shí)間公式：( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時(shí)間每秒請(qǐng)求數(shù)(QPS)機(jī)器：峰值時(shí)間每秒QPS / 單臺(tái)機(jī)器的QPS = 需要的機(jī)器

問(wèn)：每天300w PV 的在單臺(tái)機(jī)器上，這臺(tái)機(jī)器需要多少Q(mào)PS？答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

問(wèn)：如果一臺(tái)機(jī)器的QPS是58，需要幾臺(tái)機(jī)器來(lái)支持？答：139 / 58 = 3

TPS：每秒鐘處理完的事務(wù)次數(shù)，一般TPS是對(duì)整個(gè)系統(tǒng)來(lái)講的。一個(gè)應(yīng)用系統(tǒng)1s能完成多少事務(wù)處理，一個(gè)事務(wù)在分布式處理中，可能會(huì)對(duì)應(yīng)多個(gè)請(qǐng)求，對(duì)于衡量單個(gè)接口服務(wù)的處理能力，用QPS比較多。

并發(fā)量級(jí)說(shuō)明：

評(píng)價(jià)一個(gè)網(wǎng)站的“大小”，處于視角的不同，有很多種衡量的方法，類似文章數(shù)，頁(yè)面數(shù)之類的數(shù)據(jù)非常明顯，也沒有什么可以爭(zhēng)議的。但對(duì)于并發(fā)來(lái)說(shuō)，爭(zhēng)議非常之多，這里就從一個(gè)技術(shù)的角度開始，談?wù)剮讉€(gè)Web網(wǎng)站的數(shù)量級(jí)。

相信很多人談?wù)撘粋€(gè)網(wǎng)站的熱度，總免不了會(huì)詢問(wèn)日均PV，同時(shí)在線人數(shù)、注冊(cè)用戶數(shù)等運(yùn)營(yíng)數(shù)據(jù)，說(shuō)實(shí)話從技術(shù)角度來(lái)說(shuō)，這幾個(gè)數(shù)值沒有一個(gè)可以放在一起比較的——一個(gè)靜態(tài)網(wǎng)站的PV跟一個(gè)SNS類/Web Game網(wǎng)站的PV根本就不是一回事。由于互聯(lián)網(wǎng)有一個(gè)傳說(shuō)中的“3秒定律”，可能當(dāng)下更多的網(wǎng)站技術(shù)指標(biāo)要求1.5秒以內(nèi)加載整頁(yè)，或者至少可以達(dá)到閱讀的標(biāo)準(zhǔn)。如果要較真什么“同時(shí)在線”，毫不客氣的說(shuō)，對(duì)于HTTP這類短鏈接的網(wǎng)絡(luò)協(xié)議來(lái)說(shuō)，在WebSocket還不普及的時(shí)代，能統(tǒng)計(jì)在線純屬扯淡，唯一能做的只是取個(gè)時(shí)間段，計(jì)算下訪問(wèn)用戶而已。這些依然可以換算成QPS（Quest Per Second每秒請(qǐng)求數(shù)）。就并發(fā)而言，我唯一推崇的只有理論最大QPS和悲觀QPS。

這里就大致根據(jù)理論最大QPS，給網(wǎng)站做幾個(gè)分類

50QPS以下——小網(wǎng)站

沒什么好說(shuō)的，簡(jiǎn)單的小網(wǎng)站而已，你可以用最簡(jiǎn)單的方法快速搭建，短期沒有太多的技術(shù)瓶頸，只要服務(wù)器不要太爛就好。

50～100QPS——DB極限型

大部分的關(guān)系型數(shù)據(jù)庫(kù)的每次請(qǐng)求大多都能控制在0.01秒左右，即便你的網(wǎng)站每頁(yè)面只有一次DB請(qǐng)求，那么頁(yè)面請(qǐng)求無(wú)法保證在1秒鐘內(nèi)完成100個(gè)請(qǐng)求，這個(gè)階段要考慮做Cache或者多DB負(fù)載。無(wú)論那種方案，網(wǎng)站重構(gòu)是不可避免的。

300～800QPS——帶寬極限型

目前服務(wù)器大多用了IDC提供的“百兆帶寬”，這意味著網(wǎng)站出口的實(shí)際帶寬是8M Byte左右。假定每個(gè)頁(yè)面只有10K Byte，在這個(gè)并發(fā)條件下，百兆帶寬已經(jīng)吃完。首要考慮是CDN加速／異地緩存，多機(jī)負(fù)載等技術(shù)。

500～1000QPS——內(nèi)網(wǎng)帶寬極限＋Memcache極限型

由于Key/value的特性，每個(gè)頁(yè)面對(duì)memcache的請(qǐng)求遠(yuǎn)大于直接對(duì)DB的請(qǐng)求，Memcache的悲觀并發(fā)數(shù)在2w左右，看似很高，但事實(shí)上大多數(shù)情況下，首先是有可能在次之前內(nèi)網(wǎng)的帶寬就已經(jīng)吃光，接著是在8K QPS左右的情況下，Memcache已經(jīng)表現(xiàn)出了不穩(wěn)定，如果代碼上沒有足夠的優(yōu)化，可能直接將壓力轉(zhuǎn)嫁到了DB層上，這就最終導(dǎo)致整個(gè)系統(tǒng)在達(dá)到某個(gè)閥值之上，性能迅速下滑。

1000～2000QPS——FORK/SELECT，鎖模式極限型

好吧，一句話：線程模型決定吞吐量。不管你系統(tǒng)中最常見的鎖是什么鎖，這個(gè)級(jí)別下，文件系統(tǒng)訪問(wèn)鎖都成為了災(zāi)難。這就要求系統(tǒng)中不能存在中央節(jié)點(diǎn)，所有的數(shù)據(jù)都必須分布存儲(chǔ)，數(shù)據(jù)需要分布處理?？傊?，關(guān)鍵詞：分布

2000QPS以上——C10K極限

盡管現(xiàn)在很多應(yīng)用已經(jīng)實(shí)現(xiàn)了C25K，但短板理論告訴我們，決定網(wǎng)站整體并發(fā)的永遠(yuǎn)是最低效的那個(gè)環(huán)節(jié)。我承認(rèn)我生涯中從未遇到過(guò)2000QPS以上，甚至1.5K以上的網(wǎng)站，希望有此經(jīng)驗(yàn)的朋友可以一起交流下。