昨天凌晨三點，服務器突然宕機，早上起來看了一下，日志報錯、數據庫鏈接超時，cpu、內存 磁盤利用率占比虛高 ，還好當初系統采用了springcloud 架構，通過日志剖析，服務器凌晨1點-3點接發大量請求，10分鐘后宕機。一開始程序總認為是負載均衡失效，進一步分析，流量集中在inner 接口，應該是FeignClient 請求，同時日志中出現sql 批量操作，進一步確定是Eurake 負載失效或者項目內部代碼邏輯問題。
高防服務器出現堵塞的原因，代碼邏輯中使用了多線程，并且頻繁操作數據庫，導致了程序運行一段時間之后，整個運營模塊宕機。排查難點：宕機時，服務器日志丟失，MySQL數據庫 鏈接不足導致服務器宕機，而導致鏈接不足的邏輯代碼較難定位。
服務器宕機一般分為兩種：假死機和死機第一種假死機(非藍屏死機)：
1、是硬件資源暫時性地被消耗殆盡，因而無法對外部指令進行響應的現象， 通常是網站處于訪問高峰期，流量負載過大導致,帶寬等資源跑滿。
2、是否是遭受黑客入侵攻擊導致、最簡單的就是關掉服務器，等待一段時間，待服務器騰出更多的硬件資源即可恢復正常。
3、檢查是否是誤操作導致，可能原因和解決方案：進程過多或者不斷創建，耗盡資源導致。數據庫程序死鎖，應用程序異常導致，連接數過多導致。
4、數據丟失問題通常由于drop table的錯誤操作導致，并總是便隨著缺少可用備份的問題。糟糕的Schema和索引設計是第二大影響性能的問題。
5、在性能問題中，最普通的服務器宕機原因確實是運行很糟糕的SQL， 但也不一定都是這個原因，比如也有很多問題時由于服務器Bug或錯誤的行為導致的。
6、復制問題通常由于主備數據不一致導致。是否是應用程序導致內存溢出或者泄露，out of memory導致
第二種死機：如果通過ping測試服務器，鍵盤切換數字鎖定鍵(NumLock)或大寫鎖定鍵(Caps Lock)功能， 顯示器無畫面輸出，或者鼠標光標沒有任何反應則表明服務器硬件故障，這就是服務器最麻煩的宕機情況。
服務器出現宕機的原因和解決方案1、定時任務設計不合理，批量處理程序設計不合理。生產環境中 往往沒有直接登錄服務器權限，一般思路從代碼邏輯入手，畢竟MySQL Linux 或者spring cloud 都是經過時間檢驗的，服務器宕機更有可能是自己寫的代碼邏輯有問題。
2、要即時發現服務器宕機的問題。第一時間， 發現宕機的問題。如果服務器宕機時，為了避免造成不必要的損失，要盡早通知服務商解決相關問題。
3、準備2個網站空間，他們存放的內容相同，而ip不同，并且機房的地理位置不同。這樣2個主機， 同時宕機的可能性就大大降低了。第一時間發現宕機問題后，可以迅速的通過修改dnspod.com中的域名記錄，指向目前正常的網站空間。Dnspod解析生效的時間是實時的， 而一般的dns服務器，刷新時間較長，對外聲稱24小時內生效，按照實際經驗看來，差不多30分鐘內生效，否則就要檢查域名綁定是否正確了。
域名解析其實就2個步驟：aa.在dns服務器上，將域名指向ip.bb.在網站空間上，將主機綁定域名(也是在這里，申請網站備案的!)。一個是，發送給誰?另一個是，接受誰的請求?
4、數據下載至本地網絡，完成一次請求
有的朋友遇到在自己的機器上不能訪問網站。而在別人的電腦上，卻是可以打開。那測試一下是不是你所在地的網絡不穩定，而造成的訪問中斷。如果沒問題，那再通過”在線代理”打開你的網站試一試。百度一下”在線代理”，有一些網站能提供，用其它的ip，或國外ip代理訪問某個網站的服務。如果在線代理，能夠打開你的網站，基本上可以確定，你所在的本地網絡，出現了暫時的不穩定情況。
從上面幾個方面可以看出，服務器宕機是指服務器因為某些原因而導致服務器無法運轉，造成網絡無法正常使用。 對于網站來說，服務器宕機所造成影響很大，它不但造成訪客無妨對網站進行訪問，甚至還可能影響到網站在搜索引擎上的收錄和排名， 因而在租用服務器時，建議站長選擇像互聯數據這種香港新機房，宕機概率比較低。在服務器使用的過程中，服務器宕機可能都出現， 首先我們要找到服務器可能出現宕機的原因嗎，才能找到對應的解決辦法。
