原创

一个“垃圾” App,毁掉 70 万艺考生的命运?

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://csdnnews.blog.csdn.net/article/details/86065474

640?wx_fmt=gif

这两天,很多美术生的心情,都成了这样:

640?wx_fmt=jpeg

哎!你知道美术生有多苦吗?

CSDN记者刚刚采访央美毕业的职业画家黄亮,他说美术生是没有寒暑假的,因为寒暑假都是在画室度过的。

640?wx_fmt=jpeg

正在画画的美术生

天天低头画画,好多美术生小小年纪,就得了颈椎病、疼得脖子不能动;如果穿着白衣服画画,画完衣服就成了花衣服。

然而,最近全国70万左右美术生,被一个叫艺术升的App坑惨了!

640?wx_fmt=png

它自称“让艺术之路更轻松”,现实却是“让艺术之路更拥堵”!

640?wx_fmt=png

再看看艺术升App的微博背景图,还“真方便”,方便个鬼啊!

记得上初中时,一到周日下午返校,小商贩们都会涌到校门口。

因为刚返校的学生,兜里都揣着爸妈给的钱。

我的同学们,一边买着明显提过价的小商品,一边心里暗骂,就知道赚学生的钱!

日光之下没有新事,披上了科技的外衣,艺术升App完美演绎了,互联网时代的“就知道赚学生的钱”!

从网友留言,就可以知道这次事件,有多严重!

640?wx_fmt=jpeg

640?wx_fmt=other

那么,这到底是咋回事?

70万美术生被耽误报名始末

1月5日:

鲁迅美术学院和湖北美术学院,启动2019年艺考网上报名。

当天开始,有网友反映,使用艺术升App报名时,网站不断闪退,并出现乱码等,无法报名。

640?wx_fmt=other

图源见水印

1月6日早上:

开放的天津美术学院、西安美术学院报名通道,多位网友发现,依旧出现该类问题。

“从1月6日早上6点开始,艺术升APP一直到现在是崩溃的状态,页面显示的报名地点,上边就是几个问号,报考时间、报考的学校也是问号。”

640?wx_fmt=jpeg

1月6日上午:

艺术升在其官方公众号发文称:

“由于艺术升报名系统用户访问量过大,超出了艺术升报名系统的承载负荷能力。

为了提供更好的服务,艺术升逐步对服务器流量进行优化控制,进行报名系统架构升级。”

1月6日下午:

艺术升官微发布《关于2019年艺术升西安美术学院、天津美术学院考试报名情况说明》称:

2019年艺考政策调整,全国艺术校考院校减少、考点削减,加上考点容量限制等原因,造成了大量考生,集中报名院校部分考点的状况。

故出现2019年鲁迅美术学院、湖北美术学院本科招生报考通道,开通不久后,部分考点快速报满。

次日西安美术学院、天津美术学院本科招生报考人数,成5倍数增长,远超出2019报考人次预期。

因报名人数过多等因素,造成的报名系统卡顿、及暂停维护,属临时突发状况。艺术定会尽快疏通报名通道,保证考生报名通畅。”

1月7日早上:

艺术升发布《艺术升报名系统开通3天的情况说明 》称:

640?wx_fmt=jpeg

“由于排队人数过多,服务器的响应能力严重不足,导致艺术升报名系统出现了拥堵...... 

拥堵发生后,我们立即启动技术紧急预案:迅速组织阿里云、袋鼠云的高级技术专家,联系阿里云紧急增调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

【完】


640?wx_fmt=jpeg

 热 文 推 荐 

超过 C++、压制 Java 与 C,Python 拔得 TIOBE 年度编程语言!

Java JDK 收费,Android 也坐不住了,程序员们该咋办?

“iPhone 3 年内必死!”

IT 奇侠传

IPFS 深入浅出:从《黑镜》说起

☞老程序员肺腑忠告:千万别一辈子靠技术生存!

清华首批7门标杆课程,到底有多牛?

☞趣挨踢 | 关于遗留代码的那些事儿


print_r('点个好看吧!');
var_dump('点个好看吧!');
NSLog(@"点个好看吧!");
System.out.println("点个好看吧!");
console.log("点个好看吧!");
print("点个好看吧!");
printf("点个好看吧!\n");
cout << "点个好看吧!" << endl;
Console.WriteLine("点个好看吧!");
fmt.Println("点个好看吧!");
Response.Write("点个好看吧!");
alert("点个好看吧!")
echo "点个好看吧!"

640?wx_fmt=gif点击“阅读原文”,阅读CSDN博客作者@ALLENsakaru原文!

640?wx_fmt=png喜欢就点击“好看”吧!
文章最后发布于: 2019-01-07 18:52:51
展开阅读全文
0 个人打赏
私信求帮助

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503

分享到微信朋友圈

×

扫一扫,手机浏览