一個「垃圾」 App，毀掉 70 萬藝考生的命運？

這兩天，很多美術生的心情，都成了這樣：

哎！你知道美術生有多苦嗎？

CSDN記者剛剛採訪央美畢業的職業畫家黃亮，他說美術生是沒有寒暑假的，因為寒暑假都是在畫室度過的。

正在畫畫的美術生

天天低頭畫畫，好多美術生小小年紀，就得了頸椎病、疼得脖子不能動；如果穿著白衣服畫畫，畫完衣服就成了花衣服。

然而，最近全國70萬左右美術生，被一個叫藝術升的App坑慘了！

它自稱「讓藝術之路更輕鬆」，現實卻是「讓藝術之路更擁堵」！

再看看藝術升App的微博背景圖，還「真方便」，方便個鬼啊！

記得上初中時，一到周日下午返校，小商販們都會涌到校門口。

因為剛返校的學生，兜里都揣著爸媽給的錢。

我的同學們，一邊買著明顯提過價的小商品，一邊心裡暗罵，就知道賺學生的錢！

日光之下沒有新事，披上了科技的外衣，藝術升App完美演繹了，互聯網時代的「就知道賺學生的錢」！

從網友留言，就可以知道這次事件，有多嚴重！

那麼，這到底是咋回事？

70萬美術生被耽誤報名始末

1月5日：

魯迅美術學院和湖北美術學院，啟動2019年藝考網上報名。

當天開始，有網友反映，使用藝術升App報名時，網站不斷閃退，並出現亂碼等，無法報名。

圖源見水印

1月6日早上：

開放的天津美術學院、西安美術學院報名通道，多位網友發現，依舊出現該類問題。

「從1月6日早上6點開始，藝術升APP一直到現在是崩潰的狀態，頁面顯示的報名地點，上邊就是幾個問號，報考時間、報考的學校也是問號。」

1月6日上午：

藝術升在其官方公眾號發文稱：

「由於藝術升報名系統用戶訪問量過大，超出了藝術升報名系統的承載負荷能力。

為了提供更好的服務，藝術升逐步對伺服器流量進行優化控制，進行報名系統架構升級。」

1月6日下午：

藝術陞官微發布《關於2019年藝術升西安美術學院、天津美術學院考試報名情況說明》稱：

「2019年藝考政策調整，全國藝術校考院校減少、考點削減，加上考點容量限制等原因，造成了大量考生，集中報名院校部分考點的狀況。

故出現2019年魯迅美術學院、湖北美術學院本科招生報考通道，開通不久後，部分考點快速報滿。

次日西安美術學院、天津美術學院本科招生報考人數，成5倍數增長，遠超出2019報考人次預期。

因報名人數過多等因素，造成的報名系統卡頓、及暫停維護，屬臨時突髮狀況。藝術定會儘快疏通報名通道，保證考生報名通暢。」

1月7日早上：

藝術升發布《藝術升報名系統開通3天的情況說明 》稱：

「由於排隊人數過多，伺服器的響應能力嚴重不足，導致藝術升報名系統出現了擁堵......

擁堵發生後，我們立即啟動技術緊急預案：迅速組織阿里雲、袋鼠雲的高級技術專家，聯繫阿里雲緊急增調150台伺服器，共由225台伺服器組成的報考業務集群。

至1月6日17點，系統逐漸恢復，由於之前系統在線排隊用戶較多，消化用戶隊列需要一段時間，此過程考生體驗略慢。

截止1月7日凌晨2點，報名通道、及藝術陞官方App，已完全恢復正常，目前系統穩定，考生可正常進行報考。」

從技術角度來看，這屬於一場高並發事故。

如微博、12306、電商App雙十一，都是當訪問量高並發時，訪問量一下子激漲，導致伺服器支撐不起來而導致的。

下面我們回歸技術本身，作為程序員，面對如此大的高並發流量，究竟有啥辦法，來應對系統崩潰？

在此，來自CSDN的博客作者@ALLENsakaru，為我們分享了一篇如何處理高並發和單點故障的文章。

以下為全文：

如何設計一個高並發系統？

如果你確實有真才實學，在互聯網公司里，干過高並發系統，那你拿Offer，基本如探囊取物一樣簡單。

但你要真干過高並發系統，面試官絕對不會問這個問題，否則他就不太明智了。

因為真正干過高並發的人一定知道，脫離了業務的系統架構，都是紙上談兵。

真正在複雜業務場景、而且還高並發的時候，這個系統架構一定很難搞。

要理解高並發，就得從高並發的根源出發——為什麼會有高並發？為什麼高並發就很牛X？

因為剛開始，系統都是連接資料庫的，但是資料庫支撐到每秒並發兩三千的時候，基本就快完了。

資料庫如果瞬間承載每秒5000、8000、甚至上萬的並發，一定會宕機，因為比如MySQL就壓根兒扛不住這麼高的並發量。

所以為什麼高並發牛X？

因為現在網民越來越多，很多App、網站、系統承載的都是高並發請求，高峰期每秒並發量幾千都很正常。就像每年的雙十一，一年比一年的峰值高，每秒並發幾十萬，都是洒洒水。

那麼，我們可以從以下幾個方面，來進行考慮：

1、系統拆分。將一個系統拆分為多個子系統，用Dubbo來搞。然後每個系統連一個資料庫，這樣本來就一個庫，現在多個資料庫，就可以抗高並發了。

2、緩存。必須得用緩存。大部分的高並發場景，都是讀多寫少。你完全可以在資料庫和緩存里都寫一份，然後讀的時候，大量走緩存就行了。

3、MQ。必須得用MQ。

可能你還是會出現高並發寫的場景，比如說一個業務操作里，要頻繁搞資料庫幾十次，增刪改增刪改，瘋了。

那你咋辦？用MQ吧，大量寫請求灌入MQ里，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在MySQL承載範圍之內。

4、分庫分表。可能到了最後，資料庫層面還是免不了抗高並發的要求，好吧，那麼就將一個資料庫，拆分為多個庫，多個庫來抗更高的並發。

然後將一個表，拆分為多個表，每個表的數據量，保持少一點，提高SQL跑的性能。

5、讀寫分離。多數時候，資料庫可能也是讀多寫少，沒必要所有請求，都集中在一個庫上。

可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫。

6、Elasticsearch，可以考慮用ES。ES是分散式的，可以隨便擴容，分散式天然就可以支撐高並發，因為動不動就可以擴容加機器，來抗更高的並發。

如何解決單點故障？

一個網站，從基礎的硬體層、到操作系統層、到資料庫層、到應用程序層、再到網路層，都有可能產生單點故障。

如果要有效地消除單點故障，最重要的一點，是設計的時候，要盡量避免引入單點，隨著架構的變化，定期審查系統潛在的單點，也是有必要的。

大體可以從以下幾個方面，來消除單點故障：

增加硬碟，做鏡像。讓出錯的概率降低。

網卡與網線的單點問題。系統裡面最容易物理損壞的就是網線，網卡綁定（NIC bonding）是一個很簡單、很通用的辦法，建議你配置多個網卡。

SSH伺服器和Telnet伺服器共存。畢竟SSH和Telnet，都不是百分之百靠譜的事；

IDC機房的單點。由於中國特色的「南北互通」，所以選擇IDC機房的時候，一定要有冗餘。

靠譜的DNS解析。

參考鏈接：

【完】

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！