作为一个稳定的系统是不会崩溃的，这辈子都不会，要不怎么能叫稳定呢。那为什么实践中我们确实会遇到访问量过大而服务器趴窝呢？因为实际情况比较复杂。

第一个是内存的问题。服务每个请求都是要吃内存的，请求越多内存用量越大，但内存毕竟是有限的，可能是物理内存确实用光了，也可能是OS或者中间层的限制。但不管怎样，一旦发生后果严重。daemon大概率会被os杀死，或者内部出现了问题导致完全失去响应。服务器就趴窝了。

第二个是设计上的局限。有些东西设计上就不是为大负载高并发来做的。比如早年的mysql/myisam。速度快不快？飞快。但一定数据库大到一定程度，性能就会直线下降。虽然在这个阶段还只是反应慢，服务器没有趴窝，但这种慢并非是线性增长的，而是近似于指数那这样增长方式。比如100个请求的时候每个请求1秒，200个请求的时候每个1.5秒，300个请求的时候每个5秒，到了1000个的时候就每个一个小时了。就像高速公路，车少的时候大家都能跑到法定速度。车一旦增多就会堵车。更严重的是即使堵车之后即使进入的车流没有继续增加，因为出高速的车流越来越慢，堵车也会越来越严重，最后堵到所有人都堵死。到这个程度就可以认为是事实上的趴窝了，因为几乎所有人的请求都会因为超时而挂掉。

第三个是设计上的缺陷其实说第二个问题的时候已经提到这个问题了，虽然拥堵本身是等一等就能消解，但一旦系统负荷增大到远超预期，那就不一定会发生什么事。比如大量的拥堵导致缓冲区爆了，导致了一连串连锁反应，比如前面提过的内存也爆了，进而引发一些不可逆的后果，最后导致服务器宕机。

现实生活中，情况可能会更复杂，宕机可能是多重作用的结果。比如一个系统有4个节点做负载分散，哪怕4个死了3个也不会完全宕机。结果一波高峰导致其中两个节点暂时负荷变高，反映变慢。然后导致接下来短时间所有的流量都被导入剩下的两个节点，把剩下两个节点搞到完全不动了。这个时候虽然前两个反应过来了，但面对海量的求情也很快就趴窝了。毕竟是是需要四个人才能搞定的活，现在两个兄弟趴了，剩下两个孤军奋战趴也是迟早的事。这样服务器就全趴了。