回顾4日晚大学城第二轮选课

【本文非官方发布消息，仅代表小编个人观点】

回顾一下昨天大学城第二轮选课的情况，展望一下今晚的选课安排，给大家解答一下疑惑。

1

图说选课

选课对于一般同学来说

只是访问一个网站

按一下按钮

实际上你看不见的地方

运维做了很多事情

下面就从运维人员的角度

看看选课的时候发生了什么事情

上图就是昨晚的选课情况

柱子高度代表

每五分钟教务系统的访问量

（不含静态资源文件下载量）

在选课高峰期

（18:55~19:35）

每五分钟的访问量均突破10万

共计访问量PV超过120万

每分钟最高访问量发生在19:30

一共37401个请求

最高并发数发生在19:06:30

QPS达774

将近达到悲观水平

（在现在服务器资源底下的悲观水平）

19:00~20:00之间

有5629位同学 (可能重复)

选了12163次课

其中，选课高峰为19:00

一共564位同学选上了584门课

用事实说话

教务系统实际的压力是怎样的呢？

我们从

服务器整体

登录成功状态

服务器整体时延

三个大指标观察

上图为教务系统整体的访问状态报告

绿色为200状态，代表成功

橙色为302状态，代表跳转成功

红色为500状态，代表服务器程序故障

褐色为503状态，代表各服务器无响应（资源耗尽）

蓝色为504状态，代表服务器响应超时

由图可以知道

成功的请求是占绝大多数的

直到正式选课开始

才出现相对较少的故障

（数目在1000左右，人均两个错误）

上图为实际登录的状况报告

（单位为每分钟数量）

绿色代表成功登录的同学

橙色代表登录失败的同学

（账号密码错误、验证码错误）

红色代表遇到服务器故障的同学

褐色代表刷新频率过高的同学（基本没有）

由图可以看到

在正式选课开始前

基本没有服务器故障发生

成功登录的同学占绝大多数（约70%）

登录失败的同学占剩余的30%

19:00正式选课开始后

不少同学完成选课

服务器的实际选课压力也达到顶峰

服务器故障率大幅度提高

登录数量出现断崖式下降

呈现近乎成功失败故障的1:1:1的局面

19:06稍微恢复登录

19:17重启后服务器故障率大幅度下降

对比实际选课的流量图

可以发现数据是比较吻合的

上图是实际访问的延时图示

计算时间是18:40~20:00

从下到上代表具体时延范围的请求在总请求中的占比

也就是最下面的面积代表时间短的0~250毫秒

最顶上的玫红色是最慢的2分钟以上

在浏览器上感受到的

卡了、慢了、流畅

这些主观的感受均得到"量化"

由图可以看到

18:55开始出现长时间请求

19:04小重启后延时优化效果不明显

但同学们很多都登录进来了

19:07小重启后反弹

进入最缓慢的时间段

各种时延的分布比较均匀

19:17小重启后进入波动期

最后19:29响应大家的要求

来了一次大重启

19:30后优化效果明显

延时优化比较好

弹幕反馈大多数同学能成功登录

总结经验

今晚在普遍延时高时启用大重启

如果效果明显，可以在未来推广

2

弹幕答疑时间

Q: 第二轮选课是否公平?

A:绝对的公平是做不到的，只能做到相对的公平。

第一轮选课采用无人工干预的机器抽签的方式，相信大家还是认可它是公平的。

第二轮选课本质是先到先得的抢课。参与第二轮选课的同学们的差异在于自己的电脑和网络状况、实际选中的服务器、服务器的网络状况、服务器的运行状态、登录成功的时间、按下选课按钮的时间。其中，服务器的网络状况、服务器的运行状态可以说是公平的，因为开关都是大家一起来的，都在同一条起跑线上。自己电脑和网络状况的问题属于自己的问题，你需要在选课前自己解决（有些同学到开始选课了才去解决“密码框”显示不出来，按钮按不了的问题，这个是要你自己未雨绸缪的）。登录成功的时间、按下选课按钮的时间更多取决于你的手速、你对选课的专心程度。

当然，占最主要影响的还是实际抽签选中的服务器。因为现在的负载均衡采用IP分配服务器的方式，简单来说就是服务器给你抽你要哪个教务系统。而且抽取服务器也是以机器自动抽签的形式，是公平的，不受人为因素干扰的。

那你可能会说，我进都进不去，别的同学很流畅，不公平。是的，这个问题是存在的。从客观的日志数据看，有不少同学很流畅就完成了选课，与此同时不少同学卡了很久才登录进去。之所以你进不去，本质上还是你抽到了一台高负载甚至故障的教务系统。那你可能会说，我要换服务器。这个也考虑到了，所以服务器会对进入了超时服务器的同学进行重新抽签的操作，所以你会发现卡了很久之后进去了。“卡”实际上是一个等待超时的过程，让服务器缓一口气。如果超时时间减少，可能会导致同学们一下子涌入流畅的服务器，进而导致服务器全部崩溃，可能大家都选不上。

Q: 能不能改良下服务器?

A: 这个问题问的好，华师一直都在尽力改良教务系统的服务器。现在多年精心“调教”教务系统的小编每学期都会总结经验，尽力在可操作的情况下优化第二轮选课的体验。现在的教务系统是采用多台教务系统服务器负载均衡+前端高速缓存的搭配方法。分流静态文件下载，减轻教务系统的数据传输压力。负载均衡将流量均匀导入到不同的教务系统服务器中。以及一系列的网络优化，尽量在不改动教务系统程序的情况下做到最好。

那为什么会崩溃呢？作为一名程序员，很负责任的告诉你，这个是教务系统本身软件的问题。当初教务系统设计是没有针对高并发的选课进行优化的，数据库索引建立有问题，数据库的CURD逻辑未优化，Session不支持互通（验证码错误罪魁祸首），过多无意义的数据传输，图形生成消耗资源太多（验证码生成拖慢服务器），前后端不分离……最致命的是内存GC机制过糟，内存不能及时回收，非常容易耗尽内存然后崩溃。这种种问题连锁反应导致服务器极其容易变慢，直至崩溃。由于教务系统软件属于正方公司，源码只有他们的工程师才可以改，所以无法对其进行代码层面的优化。

王婆卖瓜，自卖自夸。华师已经是在有限的资源内尽量做到最优的服务。老衲黔驴技穷，黔驴技穷。

Q: 能不能换个或者自己写一个高并发的教务系统？

A: 我只能站在一个程序员的角度给大家分析。

大家可以搜一下“华工学生权益”公众号发布的《座谈会回顾｜为什么教务系统如此不稳定？》。内容简单来说就是现在市场上的教务系统（强智、青果、金智）都是差不多的，都是没有满足高并发的需求，“从国内其他兄弟院校的反馈来看，体验效果并没有很大区别，而且数据迁移可能带来数据丢失等问题，为避免造成日后的麻烦与不便，不敢轻易尝试”。

那你可能就会说，咱们写一个不就行了呗。事情可没有这么简单的！！写教务系统本身是很困难的事情！！除了很多教务系统实际的业务逻辑很难写，要实现高并发选课也是很困难的。现在华师的教务系统已经用了十几年了（也更新过很多次版本了）。如果真的要开发一个新的高并发的教务系统，一方面要有大量money（最核心问题）来请很厉害的程序员也要厉害，其次改造难度灰常大（业务逻辑过于复杂，新旧数据考虑兼容问题）。要做下去，真的是非常难得。

现在已知的定制的教务系统或者选课系统（复旦、哈工大、暨大等高校）表现也是一般般，暂时还没看到在现在的选课策略下能让大部分学生满意的教务系统。

Q: 有没有一些大学的选课流程算比较令人满意的？

A: 可以换一种选法，把先到先得变成“筹码”的意愿权重法。北大、华东师大采用这样方式进行选课，类似于菠菜，意愿值给得高的同学选中几率高，基本上是看运气。虽然服务器在绝大多数的时候轻松了，但是选课却变成了一门学问，你得好好研究研究怎么选课命中高，而不是纯拼手速。

当然，即使是这样的策略，服务器该崩溃还是会崩溃的。一般都是在选课快结束的时候，大家去改自己的意愿，大量情况压爆了服务器。必须要提的是，他们也是有先到先得的补选时间的，只是绝大多数的同学都可以在补选之前完成选课。需要补选的同学相对少很多，所以服务器的压力小很多。不说了，哪天华师也改成这样选课，记得选课的时候多点扶老奶奶过马路（笑

Q: 为什么不能教师选学生，而是学生选教师？

A: 如果我是老师，我就爱把爱学习的上课活跃积极、按时交作业、听话的同学都选了，上课就没这么累了。而且这样做就没有选课了，教务系统也会轻松很多。

可是为什么现在是“学生选教师”的大学占多数呢？举个一个例子就可以了，万一你被一位所谓的“差评”的老师选了……

学生选教师就是为了给你更多选择自由。大家都成年人啦，能自己主动选择那当然是挺好的。

Q: 要不考虑一下分学院抢课？不用整个校区挤进。

A: 这个小编没有决定权，下面也只是纸上谈兵分析一下。

我所了解的情况是原本呢设想的第二轮是三校区一起选的。但是怕服务器大规模宕机，所以才变成现在这样分开校区选。

那为什么不能分学院呢？因为公共选修课、部分公共必修课是跨学院竞争的。如果分开学院抢课，会出现一个情况，先来的学院会把“好课”选走了，这样对于后面的学院的同学是不公平的。而且开关选课不是全自动的过程，需要的人工操作太多，选课次数多了会耽误选课进程，也会影响同学们正常的学习生活（你得看着几点到几点是你们学院选课，多累呀）。

退一步，假设真的可以落实这个策略，为了确保选课容量的公平性，肯定要把每门课的容量AA了。这个需求在现在的技术上很难实现，业务逻辑过于复杂，而且对于有自信在高峰期选课的同学来说这是不公平的。

Q: 直播的时候UP主你在做什么？

A: 选课期间，UP主一直都在工作。你看到的直播界面是OBS Studio渲染出来的，并不是UP主的屏幕界面。弱弱透露一句，我的面前是两个显示屏，左边做服务器的控制的屏幕，右边看实时的统计数据和弹幕的屏幕。实时统计的数据包含每分钟的负载均衡压力分布、每30秒的响应状态和响应时间。根据客观的数据和弹幕小伙伴们的提醒，适当的对服务器进行重启的操作。直播互动的效果还是不错的，最后一轮重启让很多一直进不去的小伙伴都登进去了。

昨天晚上了解到有少数同学带了一下直播的节奏。希望你们能好好看一回直播，不要带着有色眼镜看问题，视野开阔一点，多点独立思考口巴。彳亍口马？

Q: 为什么要直播选课？

A: 首先，从去年初开始每个学期都会在B站直播的，上个学期也开了一些线下的交流。只是今年扩大了一下宣传面，知道的直播间同学更多了。今年的直播形式也是稍做改变。去年最初只是播“任务管理器”的CPU占比和内存占比，比较专业，也没有解说。现在是以图的形式直观地展示服务器响应数据的，让大家可以感受一下在客观的数据下教务系统发生了什么。

直播的初衷是希望大家可以在选课的时候给一下反馈，及时报告下大家的选课体验，以及有啥问题小编可以作为桥梁转发你们的需求到相关的老师那儿。

如果不直播的话，小编自己只能自己测试了，但是测试样本太少了，没办法直接实时了解选课的情况是怎么样的，只能靠时候问朋友们来取得反馈。

如果选课是完全的“黑箱”的话，大家在服务器崩的不会觉得有点儿“绝望”么。至少直播多了一个给你吐槽的地方，而且这个吐槽是可以得到直接反馈的。

偷偷说一下，教务处的老师晚上也是在加班，大家多多体谅一下。

Q: 能不能直播一下操作界面？

A: 为了保障服务器的网络安全，操作界面不会直播。

Q: 为什么只能靠重启来优化？

A: 因为重启已经是现在效果最好的应对教务系统高并发的实际可行的技术方法。服务器也是电脑呀，电脑坏了，咱们不也是考虑先重启，重启不行再重装嘛（小本本记下来呀）。当然，还是要强调一下，要彻底根治，只能靠改进教务系统的软件本身实现，现在都是临时应对的策略。

Q: 用校园网选课为什么会慢？

A: 没道理慢的。如果你上别的网都ok，那就是你抽到“慢”的服务器了，和校园网无关。别带校园网的节奏吧，校园网为啥我都用的好好的……你觉得你的校园网有问题，就麻烦到公众号后台留言一下。

Q: 登录的时候密码框出不来，怎么办？

A: 如果平时就是这样，那就换浏览器。如果是高峰期，请刷新页面。

Q: 选课界面很乱，按不了按钮，怎么办？

A: 换浏览器，不要犹豫了。

还有问题的话，欢迎在这篇推送下面留言，或者在直播期间到直播间发弹幕留言呀

3

直播安排