寫日志也會引發故障

故障現象：某應用服務器集群發布后不久就出現多臺服務器相繼報警，硬盤可用空間低于警戒值，并且很快有服務器宕機，登錄到線上服務器，發現log文件夾里的文件迅速增加，不斷消耗磁盤空間。 原因分析：查日志內容發現開發人員將log輸出的level全局配置為Debug，這樣一次簡單的web請求就會產生大量的log文件輸出，在高并發的用戶請求下，很快就消耗完磁盤空間。 經驗：線上的日志輸出級別至少為Warn。

高并發訪問數據庫引發故障

故障現象：某應用發布后，數據庫Load居高不下，遠超正常水平，持續報警。 原因分析：檢查數據庫，發現報警是因為某條SQL引起，這條SQL是一條簡單的有索引的數據查詢，不應該引發報警。繼續檢查，發現這條SQL執行頻率非常高，遠超正常水平。追查這條SQL，發現被網站首頁應用調用，首頁是被訪問最頻繁的網頁，這條SQL被首頁調用，也就被頻繁執行了。 經驗：首頁不應該訪問數據庫，首頁需要的數據可以從緩存服務器或者搜索引擎服務器獲取； 首頁最好是靜態的。

高并發情況下鎖引發的故障

故障現象：某應用服務器不定時因為響應超時而報警，但是很快又超時解除，恢復正常，如此反復，讓運維人員非?？鄲馈?原因分析：程序中某個單例對象(Singleton object)中多處使用了synchronized(this)，由于this對象只有一個，所有的并發請求都要排隊獲得這唯一的一把鎖。一般情況下，都是一些簡單操作，獲得鎖，迅速完成操作，釋放鎖，不會引起線程排隊。但是某個需要遠程調用的操作也被加了synchronized(this)，這個操作只是偶然被執行，但是每次執行都需要較長的時間才能完成，這段時間鎖被占用，所有的用戶線程都要等待，響應超時，這個操作執行完后釋放鎖，其他線程迅速執行，超時解除。 經驗：謹慎使用鎖。

緩存引發的故障

故障現象：沒有新應用發布，但是數據庫服務器突然Load飆升，并很快失去響應。DBA將數據庫訪問切換到備機，Load也很快飆升，并失去響應。最終引發網站全部癱瘓。 原因分析：緩存服務器在網站服務器集群中的地位一直比較低，服務器配置和管理級別都比其他服務器要低一些。人們都認為緩存是改善性能的手段，丟失一些緩存也沒有什么問題，有時候關閉一兩臺緩存服務器也確實對應用沒有明顯影響，所以長期疏于管理。結果這次一個缺乏經驗的工程師關閉了緩存服務器集群中全部的十幾臺Mencached服務器，導致了網站全部癱瘓的重大事故。 經驗：當緩存已經不僅僅是改善性能，而是成為網站架構不可或缺的一部分時，對緩存的管理就需要提高到和其他服務器一樣的級別。

應用啟動不同步引發的故障

故障現象：某應用發布后，服務器立即崩潰。 原因分析：應用程序Web環境使用Apache + JBoss的模式，用戶請求通過Apache轉發JBoss。在發布時，Apache和JBoss同時啟動，由于JBoss啟動時需要加載很多應用并初始化，花費時間較長，結果JBoss還沒完全啟動，Apache就已經啟動完畢開始接收用戶請求，大量請求阻塞在JBoss進程中，最終導致JBoss崩潰。除了這種Apache和JBoss啟動不同步的情況，網站還有很多類似的場景，都需要后臺服務準備好，前臺應用才能啟動，否則就會導致故障。這種情況被戲稱：“姑娘們還沒穿好衣服，老鴇就開門迎客了。” 經驗：就本例來說，在應用程序中加入一個特定的動態頁面(比如只返回OK)，啟動腳本先啟動JBoss，然后在腳本中不斷用curl命令訪問這個特定頁面，直到收到OK，才啟動Apache。

大文件讀寫獨占磁盤引發故障

故障現象：某應用主要功能是管理用戶圖片，接到部分用戶投訴，表示上傳圖片非常慢，原來只需要一兩秒，現在需要幾十秒，有時等半天結果瀏覽器顯示服務器超時。 原因分析：圖片需要使用存儲，最有可能出錯的地方是儲存服務器。檢查存儲服務器，發現大部分文件只有幾百KB，而有幾個文件非常大，有數百兆，讀寫這些大文件一次需要幾十秒，這段時間，磁盤基本被這個文件操作獨占，導致其他用戶的文件操作緩慢。 經驗：存儲的使用需要根據不同文件類型和用戶進行管理，圖片都是小文件，應該使用專用的存儲服務器，不能和大文件共用存儲。批處理用的大文件可以使用其他類型的分布式文件系統。

濫用生產環境引發的故障

故障現象：監控發現某個時間段，某些應用突然變慢，內部網絡訪問延遲非常厲害。 原因分析：檢查發現，該時段內網卡流量也下降，但是沒有找到原因。過了一陣子才知道，原來有工程師在線上生產環境進行性能壓力測試，占用了大部分交換機帶寬。 經驗：訪問線上生產環境要規范。網站數據庫有專門DBA維護，如果發現數據庫存在錯誤記錄，需要進行數據訂正，必須走數據訂正流程，申請DBA協助。于是就有工程師為避免麻煩，直接寫一段數據庫更新操作代碼，悄悄放到生產環境上執行，如更新影響大量數據，會導致系統處于假死狀態，如果更新錯了數據，后果更嚴重。

不規范的流程引發的故障

故障現象：某應用發布后，數據庫Load迅速飆升，超過報警值，回滾發布后報警消除。 原因分析：發現該應用發布后出現大量數據庫讀操作，而這些數據本來應該從分布式緩存讀取。檢查緩存，發現數據已經被緩存了。檢查代碼，發現訪問緩存的那段代碼被注釋掉了。原來工程師在開發的時候，為了方便測試，特意注釋掉讀取緩存的代碼，結果開發完成后忘記把注釋去掉，直接提交到代碼庫發布到線上環境。 經驗：代碼提交前使用diff命令進行代碼比較，確認沒有提交不該提交的代碼。

不好的編程習慣引發的故障

故障現象：某應用更新某功能后，有少量用戶投訴無法正常訪問該功能，一點擊就顯示出錯信息。 原因分析：分析這些用戶，都是第一次使用該功能，檢查代碼，發現程序根據歷史使用記錄構造一個對象，如果該對象為null，就會導致NullPointException。 經驗：編寫健壯的代碼。

摘自《大型網站技術架構》–李智慧

總結

以上是生活随笔為你收集整理的大型网站典型故障案例分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。