一个“垃圾” 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解析。
参考链接：
https://blog.csdn.net/ALLENsakaru/article/details/85952942
https://mp.weixin.qq.com/s/7rAp70i8Rrfi94rTskJA3g
【完】
热 文 推 荐
☞超过 C++、压制 Java 与 C，Python 拔得 TIOBE 年度编程语言！
☞Java JDK 收费，Android 也坐不住了，程序员们该咋办？
print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！\n");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"