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

當程序員開了外掛 第四十二章 大哥,你快收了神通吧

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

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

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

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

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

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

“對啊，是有什么bug了嗎？”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

宋飛翼想不明白，到底是哪個環節出了問題，居然能

把兩臺物理機給逼到這個份上。

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

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

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

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

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

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

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

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

我做了灰盒測試

程文決定還是盡早的坦白，不然被人抓到了把柄，那就不好了。

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

“測試的是那個下載的時候指定參數的

縮放。”

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

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

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

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

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

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

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

“臥槽，難道就硬生生去

縮放了，并沒有限制一下大小？”宋飛翼想到了一個可能的原因。

“大意了，大意了。”

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

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

“好的。”

大哥，你快收了神通吧！

程文：……

好，我這就把腳本停了

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

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

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

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

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