相信很多高校都会遇到这个问题，全校性的公选课是集中在一两天，由全体学生上网选课。
学生为了选到好的课，往往是公选课一开选，就纷纷登录去选课。
这样导致那一瞬间的并发访问量特别多
大家选课有2个途径
路径1：校园网用户是直接访问学校的选课的服务器，但由于服务器承受不了这么大的压力，返回大量错误（忘记了是返回什么错误，但是可以肯定的是服务器没有崩溃，因为有的人可以登录，并且成功选课，但有的人就打开不了网站）
路径2：ADSL用户通过学校的6台代理服务器访问选课的服务器，做了DNS轮询，但基本上代理全部挂掉，代理服务器是squid
有什么方法可以在不增加大量设备投入的情况下，改善这种情况呢？
因为平时服务器基本上没什么负载，就是选课这两天压力特别大，如果能有什么弹性的机制就更好
个人有个想法：
如果在前端再加一层队列机制，会不会好一点，因为运行选课程序的网站是没有崩溃的，但是直接返回错误，导致大家不停的刷新网站，给网站跟大的压力；给大家来个排队，让大家知道自己前面有多少人在等待，并提示大家不要刷新页面，会不会好点？
一个业余的人问的问题，每到选课的时候都非常头疼
学生为了选到好的课，往往是公选课一开选，就纷纷登录去选课。
这样导致那一瞬间的并发访问量特别多
大家选课有2个途径
路径1：校园网用户是直接访问学校的选课的服务器，但由于服务器承受不了这么大的压力，返回大量错误（忘记了是返回什么错误，但是可以肯定的是服务器没有崩溃，因为有的人可以登录，并且成功选课，但有的人就打开不了网站）
路径2：ADSL用户通过学校的6台代理服务器访问选课的服务器，做了DNS轮询，但基本上代理全部挂掉，代理服务器是squid
有什么方法可以在不增加大量设备投入的情况下，改善这种情况呢？
因为平时服务器基本上没什么负载，就是选课这两天压力特别大，如果能有什么弹性的机制就更好
个人有个想法：
如果在前端再加一层队列机制，会不会好一点，因为运行选课程序的网站是没有崩溃的，但是直接返回错误，导致大家不停的刷新网站，给网站跟大的压力；给大家来个排队，让大家知道自己前面有多少人在等待，并提示大家不要刷新页面，会不会好点？
一个业余的人问的问题，每到选课的时候都非常头疼
Select Language