公司有一個(gè)Web Service，訪問量不大， 但也不算小， 每天幾百萬的量級(jí)。正常情況下， 平均每個(gè)請(qǐng)求響應(yīng)的時(shí)間在200毫秒左右。
每天幾百萬的訪問量， 那么程序每秒請(qǐng)求處理數(shù)量在幾十個(gè)左右， 高峰期也就上百， 而服務(wù)器上php處理請(qǐng)求的進(jìn)程數(shù)是大于這個(gè)數(shù)的，因此， 服務(wù)器的處理能力勉強(qiáng)能滿足當(dāng)前量級(jí)的請(qǐng)求， 除了少數(shù)時(shí)候高峰期會(huì)出現(xiàn)不穩(wěn)定的狀況， 大多數(shù)時(shí)候也算是相安無事， 但是從服務(wù)器失敗請(qǐng)求的數(shù)量來看應(yīng)該離服務(wù)器處理能力極限的臨界點(diǎn)不遠(yuǎn)了。
這個(gè)Web Service有一個(gè)特點(diǎn)， 它并不是面向終端的 ， 而是為另一套Web Service提供底層數(shù)據(jù)用， 那套Web Service會(huì)進(jìn)行數(shù)據(jù)緩存，不會(huì)把所有數(shù)據(jù)請(qǐng)求轉(zhuǎn)發(fā)到我們這里，它替我們擋掉了大部份壓力。然而， 天有不測(cè)風(fēng)云，某一天高峰期那套Web Service的緩存機(jī)制壞掉了， 所有數(shù)據(jù)請(qǐng)求全都轉(zhuǎn)發(fā)到我們的Web Service上， 結(jié)果， 我們Web Service訪問量成倍增長，服務(wù)器超出了承受能力的范圍而無法正常響應(yīng)，然后用戶各種投訴，領(lǐng)導(dǎo)各種不滿，壓力自然而然就到了我的身上。
我分析了一下問題的原因，Web Service 每個(gè)請(qǐng)求的響應(yīng)時(shí)間為200毫秒上下， 服務(wù)器的并發(fā)處理能力并不是很高， 也就是說在每個(gè)200毫秒內(nèi)，服務(wù)器處理請(qǐng)求數(shù)量是有極限的， 當(dāng)每200毫秒的請(qǐng)求量大于這個(gè)極限的時(shí)候， 后面進(jìn)來的請(qǐng)求就不能被及時(shí)處理， 只能排隊(duì)等待，這就跟堵車一下，車的數(shù)量遠(yuǎn)大于馬路的吞吐量時(shí)，自然是越堵越多。堵車沒有時(shí)間限制， 反正遲早能開走， 只是花點(diǎn)時(shí)間等待而已。 而服務(wù)器處理請(qǐng)求就不一樣了，如果指定的時(shí)間范圍內(nèi)無法及時(shí)處理請(qǐng)求，那么這些請(qǐng)求就會(huì)壞掉， 也就是我們通常看到的502或者504。我們的服務(wù)器也是因?yàn)檫@個(gè)原因而出現(xiàn)了大量的壞掉的請(qǐng)求，導(dǎo)致業(yè)務(wù)受到影響。
