一、內存的問題。

服務每個請求都是要吃內存的，請求越多內存用量越大，但內存畢竟是有限的，可能是物理內存確實用光了，也可能是OS或者中間層的限制。但不管怎樣，一旦發生后果嚴重。 ?daemon大概率會被os殺死，或者內部出現了問題導致完全失去響應。服務器就趴窩了。 ?

二、設計上的局限

有些東西設計上就不是為大負載高并發來做的。比如早年的mysql/myisam。速度快不快？飛快。但一定數據庫大到一定程度，性能就會直線下降。雖然在這個階段還只是反應慢，服務器沒有趴窩，但這種慢并非是線性增長的，而是近似于指數那這樣增長方式。比如100個請求的時候每個請求1秒，200個請求的時候每個1.5秒，300個請求的時候每個5秒，到了1000個的時候就每個一個小時了。 ?就像高速公路，車少的時候大家都能跑到法定速度。車一旦增多就會堵車。更嚴重的是即使堵車之后即使進入的車流沒有繼續增加，因為出高速的車流越來越慢，堵車也會越來越嚴重，最后堵到所有人都堵死。 ?到這個程度就可以認為是事實上的趴窩了，因為幾乎所有人的請求都會因為超時而掛掉。 ?

三、設計上的缺陷

其實說第二個問題的時候已經提到這個問題了，雖然擁堵本身是等一等就能消解，但一旦系統負荷增大到遠超預期，那就不一定會發生什么事。比如大量的擁堵導致緩沖區爆了，導致了一連串連鎖反應，比如前面提過的內存也爆了，進而引發一些不可逆的后果，最后導致服務器宕機。