作为一个稳定的系统是不会崩溃的，这辈子都不会，要不怎么能叫稳定呢。那为什么实践中我们确实会遇到访问量过大而服务器趴窝呢？因为实际情况比较复杂。
第一个是内存的问题。
服务每个请求都是要吃内存的，请求越多内存用量越大，但内存毕竟是有限的，可能是物理内存确实用光了，也可能是OS或者中间层的限制。但不管怎样，一旦发生后果严重。daemon大概率会被os杀死，或者内部出现了问题导致完全失去响应。服务器就趴窝了。
第二个是设计上的局限。
有些东西设计上就不是为大负载高并发来做的。比如早年的mysql/myisam。速度快不快？飞快。但一定数据库大到一定程度，性能就会直线下降。虽然在这个阶段还只是反应慢，服务器没有趴窝，但这种慢并非是线性增长的，而是近似于指数那这样增长方式。比如100个请求的时候每个请求1秒，200个请求的时候每个1.5秒，300个请求的时候每个5秒，到了1000个的时候就每个一个小时了。就像高速公路，车少的时候大家都能跑到法定速度。车一旦增多就会堵车。更严重的是即使堵车之后即使进入的车流没有继续增加，因为出高速的车流越来越慢，堵车也会越来越严重，最后堵到所有人都堵死。到这个程度就可以认为是事实上的趴窝了，因为几乎所有人的请求都会因为超时而挂掉。
第三个是设计上的缺陷
其实说第二个问题的时候已经提到这个问题了，虽然拥堵本身是等一等就能消解，但一旦系统负荷增大到远超预期，那就不一定会发生什么事。比如大量的拥堵导致缓冲区爆了，导致了一连串连锁反应，比如前面提过的内存也爆了，进而引发一些不可逆的后果，最后导致服务器宕机。现实生活中，情况可能会更复杂，宕机可能是多重作用的结果。比如一个系统有4个节点做负载分散，哪怕4个死了3个也不会完全宕机。结果一波高峰导致其中两个节点暂时负荷变高，反映变慢。然后导致接下来短时间所有的流量都被导入剩下的两个节点，把剩下两个节点搞到完全不动了。这个时候虽然前两个反应过来了，但面对海量的求情也很快就趴窝了。毕竟是是需要四个人才能搞定的活，现在两个兄弟趴了，剩下两个孤军奋战趴也是迟早的事。这样服务器就全趴了。
总的来说，服务器挂掉，就是资源不足以支撑高并发的请求；
内存不足，数据库连接池的限制导致访问数据长时间等待导致服务超时，或者大量复制计算消耗CPU性能，都会导致服务器无法承担大量高并发的请求；
数据库，和服务器是一样的道理；
redis，或者其他的中间件，都是一样的道理；
作者：Zign
链接：https://www.zhihu.com/question/325140482/answer/688956989
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
网友评论