大并发的处理

学分制的选课历来饱受责难，每次到那个时候，服务器总要撑不住，死掉一阵。这时候就骂声不断。

 

说说我知道的比较大的系统的类似的情况：

 

日语报名：教育部的报名系统，有网通和教育网两个分站，名额有限，先到先得。12点报名，11点半访问网站还算畅快。临近12点，则基本陷入不能提供服务的状态。一直折腾到1点半才报完。

 

奥运售票：也是先到先得。结果也是撑不住，无法提供服务。具体详情不知，是从水母社区的it版讨论看到的。

 

先到先得这个说法害死人呐，这不摆明告诉用户说：come on，来试试我的服务器能力吧。

 

在讨论中，两个说法很有启发：

=======================================

"假设真正的需求是100万人都会在5分钟之内登录

如果访问是均匀的，那么系统只要支持>4k/秒的能力应该可以

问题是，其中第一分钟的时候，超过了4k/秒，假设达到10k每秒

那么至少36万人没有成功服务，他们会加入到下一个1分钟重新登录

然后第二个1分钟又产生了更多的不成功，这些人又加入到下一个1分钟

。。。

然后就造成了雪崩效果

 

其实本来100万人也许只要请求1000万个网页就完成了所有活动

结果一段时间下来，服务器被请求了上几亿次，因为平均每个人都重复了几十次"

=======================================

"中秋，春节以及穆斯林国家的开斋节都和这个差不多。

平时的时候电信的交换机的负荷连30%都不到，但是赶上几个特殊的节日的话，

话务量上涨的不是一般的多，尤其是中秋节当天晚上下班时和除夕夜敲过正点钟的那15分钟。

一般来说如果一个系统的能力是100CAPS的话，那么当业务请求达到90caps的时候就要毫不留情的在流程的最前段将业务cut掉，当然可以放行少量的VIP客户

这样可以保持业务至少已90caps的速度被消化掉。

如果不加以流量控制的话，会产生信令链路拥塞，CPU负荷过高或者系统资源被分配尽等状况，这样由于消息重传和由于业务失败导致的用户重新发起业务的开销会变得和可怕。

电信系统在这方面的经验要较这些网站多得多"

========================================

 

 

我们往往就是陷入这种滚雪球的恶性循环状态。第一批次的人就超过了服务器上限，结果部分的人完成了提交，失败的那部分累积到下一批次重复提交。

 

所以一个解决的思路似乎可以这么做：设定iis的回收条件，当超过一定负担时，马上回收（或者重启），宁肯丢失一部分处理，做到长痛不如短痛。这时比较廉价，且比较容易实施的做法。

 

剩下的就是堆服务器了。至于什么异步，提高程序效率之类的，忒难，也不能完全保证可以实现。

 

关键字：web 并发