1
virusdefender 2014-09-06 18:38:20 +08:00
教务系统比你想的要复杂的多~虽然这不是系统难用的理由
|
2
14 2014-09-06 18:43:37 +08:00
我们学校貌似是自己用Java写的……
抢课的时候高并发也是各种错误 |
3
tyhunter 2014-09-06 18:45:13 +08:00
骚年,放弃挣扎吧,一到选课时间教务系统比12306还卡,至少12306还能让我登进去,教务系统是直接验证码都刷不出来
|
4
Exin 2014-09-06 19:13:56 +08:00
突然对我校自己做的教务系统多了几分好感,几乎没卡过……
|
5
lcxseima 2014-09-06 20:51:50 +08:00
话说今天我们选课的页面是学生做的,无刷新页面。。里面引的js代码整整齐齐没压缩。。_(:з」∠)_
|
6
Sharuru 2014-09-06 20:58:39 +08:00
我们学校选课系统也是独立于主系统用JAVA写的, 偶然一次进了学校主机看了下, 因为选课和教务系统要进行课程, 老师, 教室, 日程, 学生权限(诸如处分, 学分等) 各种信息进行对接, 上上下下的关联到的表达将近三位数个...虽然很良心(?)单单选课系统有两台服务器做分流, 选课时也有学院分流, 但是每年选课的时候还是非常卡...毕竟全校这么多人的集体DDoS你扛不住啊扛不住...
(虽然自从我有权限以后, 我都是直接用管理员写我的信息) (つд⊂) |
7
shanks 2014-09-06 21:10:49 +08:00
我突然觉得,教务系统应该上云啊!
|
8
shoumu 2014-09-06 21:26:18 +08:00
说一个我们辅导员讲的,我们学校之前用的选课系统一到选课的时候就崩,然后教务请我们学院分析,最后他们得到教务系统的并发能力是两位数,而实际上选课的时候的并发达到了四位数。。。。。。
|
9
wzzyj8 2014-09-06 21:28:41 +08:00
他们的想法是:没有必要为一年只用一次的东西优化太多,不止国内,国外很多大学也都这样
不是复杂不复杂的问题,而是因为大学里面的bureaucratic system从来就是自上而下的,他们优化对他们自己几乎都没有任何好处,因为学生不会决定他们是否晋升;反而优化的不好系统崩溃了或者无法使用了他们需要承担责任 就我看到的,很多真的是懒,最起码的缓存数据库index全都不做。这就不是系统复杂性的问题,而是优化和升级的incentive到底有多少的问题 |
10
Bakemono 2014-09-06 21:32:32 +08:00
首先是技术问题。
缓存?开玩笑呢,那些老师知道什么是 memcached 么? 要死要死用 PHP 来做后端,tornado 和 node.js 应付高并发明明这么屌。 其次是资金问题。 我们学校选课有 7 台服务器,全是 Windows 2003 **虚拟机**。 有钱买好的啊倒是… 渣学校,虽然是个一本,但是老师技术真是不怎么样。 |
11
RyuZheng 2014-09-06 22:10:53 +08:00 via Android
我们学校用的正方教务系统,更加渣,不仅仅上不去选课,连选课的规则都设定的很傻比。先是预选,预选完全是随机中的,比如限制200人,如果是500人报名了,就是500人中随机选200人出来,而且每门课是独立随机的,有的人中了5门课,而有的人一门都没中。这样合理吗?这些随机中的到了正选时就直接是选上了,而没有选上的人就要在正选时抢课,这个时候完全登陆不上去,人太多了。
|
12
dorentus 2014-09-07 00:06:48 +08:00
其实大部分学校选课系统的并发访问量还没有高到要换语言或者框架的程度
就是技术不够专业、态度不够认真罢了 |
13
shangjiyu 2014-09-07 00:11:27 +08:00 via Android
类似DDoS?
|
14
darcy 2014-09-07 00:16:43 +08:00 via iPhone
一年只用一两次是不做优化的主要原因,至于实现,真的比想像复杂多了
|
15
typcn 2014-09-07 00:18:09 +08:00
我会说 按住F5会挂吗.....
|
16
Cee 2014-09-07 00:20:56 +08:00
表示大二上大作業寫的教務系統。。。
當最後用5W+用戶的數據量測試的時候真的覺得學校的系統很牛逼了。。 |
18
Automan 2014-09-07 00:44:06 +08:00
貌似在网上看到过一段教务系统的SQL, 好长一段。。。
|
19
kalasoo 2014-09-07 00:49:38 +08:00
我本科的时候学校也有这样的问题,我当时的想法是:
1. 每次提交自己的选课表,生成一个record并存储 2. 之后基于这些records形成一个list(注意,这个时候还没有对大家的选课进行操作) 3. 这个list是以“先来后到”为基准的,一个个处理 4. 处理完一个学生的record,就用另外的workers来通知学生(邮件或者是短信)你的选课结果 5. 根据结果,学生可以再登录网站修改,这个时候就再一次“先来后到” 说白了,就是将瞬间的读写逻辑操作,编程先保存大家的requests然后逐一处理。 缺点:当然就是不能即时获得结果。 |
20
faceair OP @kalasoo 你这基本就是异步IO的思路嘛,用node应该很好实现。
但是按照楼上各位所说的,复杂在于处理各种冲突情况,比如选课不能与其他课程时间冲突,不能选一个课程两次(上一轮选课的也算),一次选课总课程不能超过2门,不能选其他系/专业的课程等等,如果都要即时验证这些数据可能就很麻烦,所以系统压力不在于是否还有剩余名额。 |
21
seki 2014-09-07 02:04:25 +08:00
这就是一个小型的 12306 嘛
原理上其实都有思路,但是……就算真的有技术牛的公司辛辛苦苦做出来了这么一套不卡还好用的系统,这些学校也是不会买的,原因你懂的 |
22
WildCat 2014-09-07 07:58:14 +08:00 via iPhone
我们学校教务系统选课挂503,查期末成绩也得挂一周。还是大名鼎鼎的正方。
|
23
ehs2013 2014-09-07 08:55:02 +08:00
URP 教务系统表示数据库挂了好几个小时
|
25
jsq2627 2014-09-07 09:38:06 +08:00
教务的逻辑也是很复杂的。教务首要保证的是功能完整,至于性能……
|
28
crystaldust 2016-02-04 10:41:23 +08:00
别难为学校的系统了,选课的时候大家都去抢,贴好了课程代码就疯狂的点鼠标发请求。一个学校研究生加本科小两万了,平均每人一秒点 3 次,并发也在 50k 了,所以学校系统能扛住 C10K 的问题,也可以啦,啊哈哈。
|