公司有一個Web Service，訪問量不大， 但也不算小， 每天幾百萬的量級。正常情況下， 平均每個請求響應(yīng)的時間在200毫秒左右。
每天幾百萬的訪問量， 那么程序每秒請求處理數(shù)量在幾十個左右， 高峰期也就上百， 而服務(wù)器上php處理請求的進(jìn)程數(shù)是大于這個數(shù)的，因此， 服務(wù)器的處理能力勉強(qiáng)能滿足當(dāng)前量級的請求， 除了少數(shù)時候高峰期會出現(xiàn)不穩(wěn)定的狀況， 大多數(shù)時候也算是相安無事， 但是從服務(wù)器失敗請求的數(shù)量來看應(yīng)該離服務(wù)器處理能力極限的臨界點(diǎn)不遠(yuǎn)了。
這個Web Service有一個特點(diǎn)， 它并不是面向終端的 ， 而是為另一套Web Service提供底層數(shù)據(jù)用， 那套Web Service會進(jìn)行數(shù)據(jù)緩存，不會把所有數(shù)據(jù)請求轉(zhuǎn)發(fā)到我們這里，它替我們擋掉了大部份壓力。然而， 天有不測風(fēng)云，某一天高峰期那套Web Service的緩存機(jī)制壞掉了， 所有數(shù)據(jù)請求全都轉(zhuǎn)發(fā)到我們的Web Service上， 結(jié)果， 我們Web Service訪問量成倍增長，服務(wù)器超出了承受能力的范圍而無法正常響應(yīng)，然后用戶各種投訴，領(lǐng)導(dǎo)各種不滿，壓力自然而然就到了我的身上。
我分析了一下問題的原因，Web Service 每個請求的響應(yīng)時間為200毫秒上下， 服務(wù)器的并發(fā)處理能力并不是很高， 也就是說在每個200毫秒內(nèi)，服務(wù)器處理請求數(shù)量是有極限的， 當(dāng)每200毫秒的請求量大于這個極限的時候， 后面進(jìn)來的請求就不能被及時處理， 只能排隊等待，這就跟堵車一下，車的數(shù)量遠(yuǎn)大于馬路的吞吐量時，自然是越堵越多。堵車沒有時間限制， 反正遲早能開走， 只是花點(diǎn)時間等待而已。 而服務(wù)器處理請求就不一樣了，如果指定的時間范圍內(nèi)無法及時處理請求，那么這些請求就會壞掉， 也就是我們通?？吹降?02或者504。我們的服務(wù)器也是因為這個原因而出現(xiàn)了大量的壞掉的請求，導(dǎo)致業(yè)務(wù)受到影響。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學(xué)習(xí)是年輕人改變自己的最好方式