服務爲何會崩潰

1.概述

最近看了一篇關於熱key致使redis服務集羣掛掉的文章， 很是的精彩致使我在想當流量很是大時爲何redis服務會掛掉，因而我就找了大量的資料研究服務爲何會掛掉及其原理，服務器爲何會宕機等等就有了以下內容。

其實服務崩潰總結起來無非就兩種，一種是資源枯竭致使的服務崩潰，另外一種就是超時引發的服務崩潰。

2.資源枯竭致使

先說第一種資源枯竭致使的服務崩潰，顧名思義就是由於服務器的資源或者分配的資源不能知足服務運行的須要從而引起服務崩潰。比較常見有內存溢出，磁盤滿載，帶寬不足等三種。

寫java的程序員遇到最多的估計就是內存溢出了，好比操做系統給jvm分配了2G的物理內存供程序運行使用，可能有個程序頭鐵在一段代碼中建立了循環引用的對象或者大量未能及時回收的對象，在請求量大時gc不能及時回收垃圾對象致使堆內存一直在增大超過了操做系統所分配的2G內存，此時就會觸發操做系統的kill -9信號把程序殺死這樣用戶再請求服務時就無響應了。

電商大促期間前有不少準備工做，其中有一項就是去運營商那裏購買寬帶，這是由於在大促期間有大量用戶訪問，若是機器帶寬不足會致使服務崩潰，進而致使很是大損失。咱們以一臺機器80M的寬帶爲例，通過計算能承受的最大下載速度就是10M/s， 拿單個用戶的一個請求數據大小爲10k爲例，在1s內有1024個用戶請求時須要80M的寬帶機器恰好能知足要求，若是是1s內有2000用戶請求時須要160M的流量那麼處理完這2000個用戶的請求須要2s，若是持續30s都有2000個用戶來請求服務，那麼就須要4800M的流量處理完須要600多s那麼就會大量請求出現等待進而引起超時致使服務崩潰。

3.超時致使

第二種超時引發的服務崩潰，就是大量用戶請求服務時由於大面積鏈接超時致使服務崩潰，和寬帶不足的例子很像，咱們以單臺機器服務啓動單進程爲例，在一個進程中咱們一般會經過線程池去處理請求，咱們假設線程池中一共有1000個請求來處理請求且每一個請求的響應時間爲100ms，當1s鐘有10000個請求發來時咱們能夠很快的處理並返回，當1s內有20000個請求發來時服務器要處理就須要2s鐘的時間了，那麼在一段持續時間20000請求來時就會積壓大量的請求不能被處理致使超時，而後後面過來的請求確定超時，這樣服務就崩潰了。

4.總結

在真實的生產環境，崩潰的緣由可能會很是複雜且是多種因素互相做用的結果，但瞭解了服務奔潰的本質後就能很快找到對應的解決方案，如萬能的增長機器，優化代碼邏輯，加入緩存等等。完畢！