一. 問題描述

　　我們去面試時，有些面試官會經常問我們：你都遇到過哪些線上的故障?是解決這些線上故障的?今天千鋒就給大家講解一個比較奇葩的線上故障，問題如下所示：

　　線上集群中，某一臺服務器頻繁重啟是怎么回事?如何解決?

　　下面是千鋒的線上服務器架構圖：

　　二. 問題排查

　　為什么會出現線上某臺服務器頻繁重啟呢?為了搞清楚問題所在，我們可以按照如下思路來進行問題排查。

　　首先我給大家說明一下，千鋒的線上服務器，請求負載均衡策略是采用的是輪詢機制，請求數量平均分配。

　　接下來我們可以定位一下故障發生的時間點。在本案例中，我的線上服務器重啟的時間段基本是固定的，所以我就可以在那個特定的時間段內進行監控。

　　然后我們再來分析一下，服務器重啟可能有哪些常見的原因：

　　硬件風扇散熱不好，造成服務器過熱，服務器會重啟---->我的服務器風扇沒有問題，排除掉;

　　檢查內存空間是否充足。可以在那個時間段通過top命令監控CPU和內存的利用率，看看是否在那個時間段內硬件資源消耗殆盡了;

　　軟件原因。服務器內部是否有什么任務代碼，在那個時間段會將硬件資源耗盡，造成重啟。

　　通過以上排查方法，我既沒有發現風扇有問題，也沒有發現在服務器中除了當前自己的應用外，還有其他大型應用在占用硬件資源。但通過top命令，我卻在服務器經常重啟的時間段內，發現硬件CPU和內存資源在某一個時間段內提升地特別快，進而造成硬件資源耗盡，服務器重啟。

　　那么如果在沒有外部軟件占用資源的情況下，CPU和內存資源的消耗更多地是由自己的軟件耗盡的。所以現在我們可以初步診斷出，是當前自己的應用在處理請求能力上較差，造成大量請求累積。

　　為了驗證結論是否正確，千鋒使用了jmeter壓力測試工具，對集群中幾臺沒有問題的服務器和當前服務器進行測試對比，結果發現當前出現問題的服務器在處理請求能力上與其他服務器相比速度較慢。

　　最終，千鋒通過以上經驗推測和測試方法得出結果，之所以會出現線上服務器經常重啟，此處主要是因為某臺服務器硬件性能較差，在輪詢策略分配請求時，平均分配造成當前機器請求的積壓過多，承載不了，從而產生系統重啟。

　　三. 解決方案

　　針對這個問題，解決方案如下:

　　修改分布式請求策略。雖然輪詢策略平均分配了請求數，但由于不同配置的機器對相同請求的處理能力不同，有可能會出現個別服務器無法承載過多壓力而崩潰的情況;

　　給請求的機器地址添加權重。我們也可以給出現問題的機器分配較少的權重，在請求分配時，給配置較低的服務器少分配一些權重，避免造成請求積壓。

　　現在你知道如何排查線上服務器的類似故障了嗎?如果你還有其他問題，可以在評論區留言哦。關注Java架構棧，干貨天天都不斷哦。