一、内存的问题。
服务每个请求都是要吃内存的,请求越多内存用量越大,但内存毕竟是有限的,可能是物理内存确实用光了,也可能是OS或者中间层的限制。但不管怎样,一旦发生后果严重。 daemon大概率会被os杀死,或者内部出现了问题导致完全失去响应。服务器就趴窝了。
二、设计上的局限
有些东西设计上就不是为大负载高并发来做的。比如早年的mysql/myisam。速度快不快?飞快。但一定数据库大到一定程度,性能就会直线下降。虽然在这个阶段还只是反应慢,服务器没有趴窝,但这种慢并非是线性增长的,而是近似于指数那这样增长方式。比如100个请求的时候每个请求1秒,200个请求的时候每个1.5秒,300个请求的时候每个5秒,到了1000个的时候就每个一个小时了。 就像高速公路,车少的时候大家都能跑到法定速度。车一旦增多就会堵车。更严重的是即使堵车之后即使进入的车流没有继续增加,因为出高速的车流越来越慢,堵车也会越来越严重,最后堵到所有人都堵死。 到这个程度就可以认为是事实上的趴窝了,因为几乎所有人的请求都会因为超时而挂掉。
三、设计上的缺陷
其实说第二个问题的时候已经提到这个问题了,虽然拥堵本身是等一等就能消解,但一旦系统负荷增大到远超预期,那就不一定会发生什么事。比如大量的拥堵导致缓冲区爆了,导致了一连串连锁反应,比如前面提过的内存也爆了,进而引发一些不可逆的后果,最后导致服务器宕机。