雖然報警是來自開環境，但是這個產品的意義重大，他們可是立了軍令狀的，如果有問題，他們就要提頭去見了。
說實在的他們也工作了有好幾年了，像這種專案他們也是頭一遭遇到，這可是有關他們的去留問題。
報警是在開環境，這對於他們來說那太好了。
找到了問題解決後，上線就不會有同樣的問題了，如果沒有在開環境沒有現，而是到了線上才有的這個問題，那他們就真的沒法交代了。
在回去的路上，他們幾個開還在交流。
“到底是怎麼回事，為什麼開環境的負載會突然升高？”
“對啊，是有什麼bug了嗎？”
“一切都等回去了我們好好的檢查檢查程式碼，一定要找出來原因，不能帶著問題上線。”這是他們開的1eader說的。
宋飛翼主導了這一次開的整體架構，是開團隊的負責人，也是架構師，這次的技術選型什麼的都是他在搞。
他的這一次的技術選型自認為還是非常不錯的，上傳的時候不管是二進位制還是需要從別的網站抓取的ur1，他是先放入到了一個本地的redis（一個記憶體資料庫，度非常快），同時也把這個資訊寫入到了訊息佇列中。
這樣就可以利用線上n多臺物理機來做分散式的操作。
這樣做不僅可以避免都訪問一個主redis的壓力，還能利用多臺機器上的記憶體，直接連的是本機的資料庫，所以讀寫度也會非常快。
把資料放到本地之後，會有返回一個任務的標誌給上傳端，這個任務的資料是寫到公共的資料庫中的。
因為上傳端可能會過一會兒就來問一下，剛才那個圖片上傳成功了沒，如果成功了訪問地址是什麼，如果沒有成功也告訴我一下，我一會兒再來問一下。
但是上傳端來問的時候，伺服器端是有負載均衡的。（一個出口，後面掛了好多個機器，可以想像一下百度的域名，他下面是有好多的物理機的，但是對外只暴露了一個域名，就是baidu，同理，其它大型的網站也基本是這個套路，不過沒有百度那麼多的機器罷了）
有負載均衡，所以不確實這個提問的動作會具體的落到哪一臺，實際上大機率都不會是剛才上傳的那一臺了。
所以這個時候有人來問了，就需要任何一個機器都能訪問到的主庫，可以從這裡取出來剛才那個上傳任務的一些資訊，返回給那個詢問的人。
這是客戶端輪詢來要結果，其實還有一個是回撥，就是在上傳圖片的時候就寫好，一個通知介面，如果成功了，伺服器端就呼叫一下這個介面，告訴它結果。
然後就是上傳的機器怎麼把圖片的資料存起來的問題了。
宋飛翼在每個機器上啟動了一個任務排程系統。
這個排程系統會依次把剛才那個訊息佇列中的訊息給消費者，消費者去真正的執行上傳的操作。
其實說白了也就是把一個二進位制的資料存到了一個資料庫叢集中，不過這個是一個特殊的資料庫，並不是常見的mysq1（也是一個資料庫，內容存在磁碟裡）。
接著再更新一下公共資料庫的資訊，這樣再有人來問的時候，它就能告訴對方應該用哪個地址來訪問。
這樣的架構用線上上是很好的，但是用在開環境基本沒有什麼太大的用途。
畢竟開環境只有兩個物理機而已，不能揮出來他設計的這一套架構的優勢。
其實一般的情況下開環境都用的是虛擬機器，還是低配的那種，而且還有很多的專案都是共用這個。
宋飛翼說他們的開環境只有兩個物理機還而已，就太氣人了。
可就算不能揮出來這個架構的優勢，那也不應該報警啊！
宋飛翼想不明白，到底是哪個環節出了問題，居然能把兩臺物理機給逼到這個份上。
回到了工位，他們立刻就登入上了機器檢視問題。
不過那兩臺伺服器卡的厲害，他們登上去都慢的很。
用1inux（和indons、macos，是一個作業系統，網際網路伺服器多用這種系統）特有的幾個命令，很快他們就看到了問題出在哪裡。
是cpu佔用的特別高，所以把整個系統的負載給拉上去了。
網路連線、檔案讀寫、記憶體都還好。
