作为一个稳定的系统，它不会崩溃，这辈子也不会，怎么能称之为稳定。那么为什么我们在实践中实际会遇到流量过大、服务器倒巢的情况呢？因为实际情况比较复杂。
首先是内存问题。服务每个请求都需要内存。请求越多，内存使用量就越大。但是，内存毕竟是有限的。可能是物理内存真的用完了，也可能是操作系统或中间层的限制。但无论如何，一旦发生，后果是很严重的。大概率会被os杀死，或者内部有问题导致它完全失去响应。服务器已关闭。
第二个是设计限制。有些东西不是为高负载和高并发设计的。比如早年的mysql/. 快吗？快速地。但是某个数据库大到一定程度，性能就会直线下降。虽然现阶段只是响应慢，而且服务器也不是窝在窝里，但是这种慢并不是线性增长，而是近似指数增长的方式。比如100个请求，每个请求1秒，200个请求，每个1.5秒，300个请求，每个5秒，达到1000个，每个1小时. 就像高速公路一样，当车少的时候，每个人都可以跑到法定速度。一旦汽车数量增加，就会出现交通拥堵。什么 更严重的是即使堵车后进来的车流没有继续增加，因为从高速出来的车流越来越慢，堵车会越来越严重服务器宕机，最后大家都是被封锁。从这个意义上说，它可以被认为是一个事实上的嵌套，因为几乎所有的请求都会因为超时而挂起。
三是设计缺陷。其实这个问题在提到第二个问题的时候就已经提到了。虽然拥塞本身可以在等待之后解决，但一旦系统负载增长远超预期，可能就不是这样了。发生了什么。比如大量拥塞导致缓冲区爆裂，导致一系列连锁反应，比如前面提到的内存爆裂，造成了一些不可逆转的后果，最终导致服务器崩溃。
在现实生活中，情况可能更复杂，停机时间可能是多个动作的结果。例如，如果一个系统有 4 个节点进行负载分配，即使 4 个节点死掉，3 个节点也不会完全关闭。结果，一波峰值导致其中两个节点的负载暂时增加，从而减慢了响应速度。然后所有流量将在短时间内引导到剩余的两个节点，使剩余的两个节点完全静止。这时候，前两个虽然反应了过来，但面对海量的哀求，却是迅速落入了巢穴。毕竟，完成这项工作需要四个人。现在兄弟二人都躺下了，剩下的两个人单独战斗也只是时间问题了。所以服务器全部关闭。
