作為一個穩(wěn)定的系統(tǒng)是不會崩潰的，這輩子都不會，要不怎么能叫穩(wěn)定呢。那為什么實踐中我們確實會遇到訪問量過大而服務器趴窩呢？因為實際情況比較復雜。**個是內(nèi)存的問題。服務每個請求都是要吃內(nèi)存的，請求越多內(nèi)存用量越大，但內(nèi)存畢竟是有限的，可能是物理內(nèi)存確實用光了，也可能是OS或者中間層的限制。但不管怎樣，一旦發(fā)生后果嚴重。daemon大概率會被os殺死，或者內(nèi)部出現(xiàn)了問題導致完全失去響應。服務器就趴窩了。第二個是設計上的局限。有些東西設計上就不是為大負載高并發(fā)來做的。比如早年的服務器速度快不快？飛快。但一定數(shù)據(jù)庫大到一定程度，性能就會直線下降。雖然在這個階段還只是反應慢，服務器沒有趴窩，但這種慢并非是線性增長的，而是近似于指數(shù)那這樣增長方式。比如100個請求的時候每個請求1秒，200個請求的時候每個1.5秒，300個請求的時候每個5秒，到了1000個的時候就每個一個小時了。就像高速公路，車少的時候大家都能跑到法定速度。車一旦增多就會堵車。更嚴重的是即使堵車之后即使進入的車流沒有繼續(xù)增加，因為出高速的車流越來越慢，堵車也會越來越嚴重，**堵到所有人都堵死。到這個程度就可以認為是事實上的趴窩了，因為幾乎所有人的請求都會因為超時而掛掉。第三個是設計上的缺陷其實說第二個問題的時候已經(jīng)提到這個問題了，雖然擁堵本身是等一等就能消解，但一旦系統(tǒng)負荷增大到遠超預期，那就不一定會發(fā)生什么事。比如大量的擁堵導致緩沖區(qū)爆了，導致了一連串連鎖反應，比如前面提過的內(nèi)存也爆了，進而引發(fā)一些不可逆的后果，**導致服務器宕機。現(xiàn)實生活中，情況可能會更復雜，宕機可能是多重作用的結果。比如一個系統(tǒng)有4個節(jié)點做負載分散，哪怕4個死了3個也不會完全宕機。結果一波高峰導致其中兩個節(jié)點暫時負荷變高，反映變慢。然后導致接下來短時間所有的流量都被導入剩下的兩個節(jié)點，把剩下兩個節(jié)點搞到完全不動了。這個時候雖然前兩個反應過來了，但面對海量的求情也很快就趴窩了。畢竟是是需要四個人才能搞定的活，現(xiàn)在兩個兄弟趴了，剩下兩個孤軍奮戰(zhàn)趴也是遲早的事。這樣服務器就全趴了。