設置
上一章
下一章
書頁

第四十二章 大哥,你快收了神通吧

請牢記域名:黃金屋 當程序員開了外掛

  雖然報警是來自開發環境,但是這個產品的意義重大,他們可是立了軍令狀的,如果有問題,他們就要提頭去見了。

  說實在的他們也工作了有好幾年了,像這種項目他們也是頭一遭遇到,這可是有關他們的去留問題。

  報警是在開發環境,這對于他們來說那太好了。

  找到了問題解決后,上線就不會有同樣的問題了,如果沒有在開發環境沒有發現,而是到了線上才有的這個問題,那他們就真的沒法交代了。

  在回去的路上,他們幾個開發還在交流。

  “到底是怎么回事,為什么開發環境的負載會突然升高?”

  “對啊,是有什么bug了嗎?”

  “一切都等回去了我們好好的檢查檢查代碼,一定要找出來原因,不能帶著問題上線。”這是他們開發的leader說的。

  宋飛翼主導了這一次開發的整體架構,是開發團隊的負責人,也是架構師,這次的技術選型什么的都是他在搞。

  他的這一次的技術選型自認為還是非常不錯的,上傳的時候不管是二進制還是需要從別的網站抓取的url,他是先放入到了一個本地的redis(一個內存數據庫,速度非常快),同時也把這個信息寫入到了消息隊列中。

  這樣就可以利用線上n多臺物理機來做分布式的操作。

  這樣做不僅可以避免都訪問一個主redis的壓力,還能利用多臺機器上的內存,直接連的是本機的數據庫,所以讀寫速度也會非常快。

  把數據放到本地之后,會有返回一個任務的標志給上傳端,這個任務的數據是寫到公共的數據庫中的。

  因為上傳端可能會過一會兒就來問一下,剛才那個圖片上傳成功了沒,如果成功了訪問地址是什么,如果沒有成功也告訴我一下,我一會兒再來問一下。

  但是上傳端來問的時候,服務器端是有負載均衡的。(一個出口,后面掛了好多個機器,可以想像一下百度的域名,他下面是有好多的物理機的,但是對外只暴露了一個域名,就是baidu,同理,其它大型的網站也基本是這個套路,不過沒有百度那么多的機器罷了)

  有負載均衡,所以不確實這個提問的動作會具體的落到哪一臺,實際上大概率都不會是剛才上傳的那一臺了。

  所以這個時候有人來問了,就需要任何一個機器都能訪問到的主庫,可以從這里取出來剛才那個上傳任務的一些信息,返回給那個詢問的人。

  這是客戶端輪詢來要結果,其實還有一個是回調,就是在上傳圖片的時候就寫好,一個通知接口,如果成功了,服務器端就調用一下這個接口,告訴它結果。

  然后就是上傳的機器怎么把圖片的數據存起來的問題了。

  宋飛翼在每個機器上啟動了一個任務調度系統。

  這個調度系統會依次把剛才那個消息隊列中的消息給消費者,消費者去真正的執行上傳的操作。

  其實說白了也就是把一個二進制的數據存到了一個數據庫集群中,不過這個是一個特殊的數據庫,并不是常見的mysql(也是一個數據庫,內容存在磁盤里)。

  接著再更新一下公共數據庫的信息,這樣再有人來問的時候,它就能告訴對方應該用哪個地址來訪問。

  這樣的架構用在線上是很好的,但是用在開發環境基本沒有什么太大的用途。

  畢竟開發環境只有兩個物理機而已,不能發揮出來他設計的這一套架構的優勢。

  其實一般的情況下開發環境都用的是虛擬機,還是低配的那種,而且還有很多的項目都是共用這個。

  宋飛翼說他們的開發環境只有兩個物理機還而已,就太氣人了。

  可就算不能發揮出來這個架構的優勢,那也不應該報警啊!

宋飛翼想不明白,到底是哪個環節出了問題,居然能  把兩臺物理機給逼到這個份上。

  不過那兩臺服務器卡的厲害,他們登上去都慢的很。

  用linux(和windowns、macos,是一個操作系統,互聯網服務器多用這種系統)特有的幾個命令,很快他們就看到了問題出在哪里。

  是cpu占用的特別高,所以把整個系統的負載給拉上去了。

  網絡連接、文件讀寫、內存都還好。

  “cpu為什么會占用的這么多。”他們看了一下進程,是nginx(一個web服務器)進程占用了很高的cpu。

  有一個人在測試群里問了一下,“大家有做過什么操作嗎?現在服務器卡的很,負載特別高。”

  好幾個人都說沒有做什么特殊的操作。

  程文也看到了這個消息,他在內心深處想,不會是我的問題吧?

我做了灰盒測試  程文決定還是盡早的坦白,不然被人抓到了把柄,那就不好了。

  “灰盒測試,你是測試了哪里的功能?”有一個開發直接找過來了。

“測試的是那個下載的時候指定參數的  縮放。”

  “好的,多謝,我知道是哪里的問題了,我去看一下。”

  當他回到他的工位上的時候,宋飛翼也從nginx的日志上看到了一些端倪。

  好像是有幾個請求導致的這個問題。

  “應該是縮放那里的問題。”直接跑去問程文的那個開發,立刻對其他人說道。

  “嗯,我也找到了這個問題,這個參數怎么這么大?”宋飛翼從日志中看到了一個有問題的參數。

  縮放的時候一般都是有固定的大小的,幾百乘幾百,最多也就幾千乘幾千,但是這幾個訪問的連接,光是url顯示出來就有十幾厘米長。

  屏幕上看別的請求都很正常,但這個都多換了一行。

“臥槽,難道就硬生生去  縮放了,并沒有限制一下大小?”宋飛翼想到了一個可能的原因。

  “大意了,大意了。”

  嘴里說著這些,手上的動作卻是一點也沒有停。

  “你先讓程文把他的腳本停一下吧,我知道問題了,馬上就修改。”宋飛翼對剛才回來的那個人說道。

  “好的。”

  大哥,你快收了神通吧!

  程文:……

好,我這就把腳本停了  程文知道已經找出來了問題,他也非常開心,總算是在上線之前找到了bug,這樣就不怕上線的時候會有重大的事故了。

  要不然不僅開發有責任,他們這些測試同樣也有責任,誰讓他們沒有測試出來這個問題。

  其實其他人也測試到了這個功能,只是他們沒有用那么大的值去測試。

  這個是在實際中是遇到的一個案例,項目已經穩定的運行了好多年了,從來沒有過問題,但是有一次突然出現了問題,后來排查問題,發現有這么一個bug。

  不知道是在當初就有,還是中間被人改過,反正線上是有這個問題的。

請記住本站域名: 黃金屋
上一章
書頁
下一章