記一次JVM FullGC引發嚴重線上事故的定位、分析、解決過程!
這篇文章給大家聊一次線上生產系統事故的解決經歷,其背後代表的是線上生產系統的JVM FullGC可能引發的嚴重故障。
先簡單說說線上生產系統的一個背景,因為僅僅是文章作為案例來講,所以弱化大量的業務背景。
簡單來說,這是一套分散式系統,系統A需要將一個非常核心以及關鍵的資料透過網路請求,傳輸給另外一個系統B。
所以這裡其實就考慮到了一個問題,如果系統A剛剛將核心資料傳遞給了系統B,結果系統B莫名其妙當機了,豈不是會導致資料丟失?
所以在這個分散式系統的架構設計中,採取了非常經典的一個Quorum演算法。
這個演算法簡單來說,就是系統B必須要部署奇數個節點,比如說至少部署3臺機器,或者是5臺機器,7臺機器,類似這樣子。
然後系統A每次傳輸一個資料給系統,都必須要對系統B部署的全部機器都傳送請求,將一份資料傳輸給系統B部署的所有機器。
要判定系統A對系統B的一次資料寫是成功的,要求系統A必須在指定時間範圍內對超過Quorum數量的系統B所在機器傳輸成功。
舉個例子,假設系統B部署了3臺機器,那麼他的Quorum數量就是:3 / 2 + 1 = 2,也就是說系統B的Quorum數量就是:所有機器數量 / 2 + 1。
所以系統A要判定一個核心資料是否寫成功,如果系統B一共部署了3臺機器的話,那麼系統A必須在指定時間內收到2臺系統B所在機器返回的寫成功的響應。
此時系統A才能認為這條資料對系統B是寫成功了。這個就是所謂的Quorum機制。
也就是說,分散式架構下,系統之間傳輸資料,一個系統要確保自己給另外一個系統傳輸的資料不會丟失,必須要在指定時間內,收到另外一個系統Quorum(大多數)數量的機器響應說寫成功。
這套機制實際上在很多分散式系統、中介軟體系統中都有非常廣泛的使用,我們線上的分散式系統也是採用了這個Quorum機制在兩個系統之間傳輸資料。
給大家上一張圖,一起來看一下這套架構長啥樣。
如上圖所示,圖中很清晰的展示了系統A和系統B之間傳輸一份資料時的Quorum機制。
接下來,我們用程式碼給大家展示一下,上面的Quorum寫機制在程式碼層面大概是什麼樣子的。
PS:因為實際這套機制涉及大量的底層網路傳輸、通訊、容錯、最佳化的東西,所以下面程式碼經過了大幅度簡化,僅僅表達出了一個核心的意思。
上面就是經過大幅精簡後的程式碼,不過核心的意思是表達清晰了。大家可以仔細看兩遍,其實還是很容易弄懂的。
這段程式碼其實含義很簡單,說白了就是非同步開啟執行緒傳送資料給系統B所有的機器,同時進入一個while迴圈等待系統B的Quorum數量的機器返回響應結果。
如果超過指定超時時間還沒收到預期數量的機器返回結果,那麼就判定系統B部署的叢集出現故障,接著讓系統A直接退出,相當於系統A當機。
整個程式碼,就是這麼個意思!
光是看程式碼其實沒啥難的,但是問題就在於線上執行的時候,可不是跟你寫程式碼的時候想的一樣簡單。
有一次線上生產系統執行的過程中,整體系統負載都很平穩,本來是不應該有什麼問題,但是結果突然收到報警,說系統A突然當機了。
然後就開始進行排查,左排查右排查,發現系統B叢集都好好的,不應該有問題。
然後再查查系統A,發現系統A別的地方也沒什麼問題。
最後結合系統A自身的日誌,以及系統A的JVM FullGC進行垃圾回收的日誌,我們才算是搞清楚了具體的故障原因。
其實原因非常的簡單,就是系統A線上上執行一段時間後,會偶發性的進行長時間Stop the World的JVM FullGC,也就是大面積垃圾回收。
但是,此時會造成系統A內部的工作執行緒大量的卡頓,不再工作。要等JVM FullGC結束之後,工作執行緒才會恢復運作。
我們來看下面那個程式碼片段:
但是這種系統A的莫名當機是不正確的,因為如果沒有JVM FullGC,本來上面那個if語句是不會成立的。
他會停頓1秒鐘進入下一輪while迴圈,接著就可以收到系統B返回的Quorum數量的結果,這個while迴圈就可以中斷,繼續執行了。
結果因為出現了JVM FullGC卡頓了幾十秒,導致莫名其妙就觸發了if判斷的執行,系統A莫名其妙就退出當機了。
所以,線上JVM FullGC導致的系統長時間卡頓,是造成系統不穩定執行的隱形殺手之一!
至於上述程式碼穩定性的最佳化,也很簡單。我們只要在程式碼里加入一些東西,監控一下上述程式碼中是否發生了JVM FullGC。
如果發生了JVM FullGC,就自動延長expireTime就可以了。
比如下面程式碼的改進:
透過上述程式碼的改進,就可以有效的最佳化線上系統的穩定性,保證其在JVM FullGC發生的情況下,也不會隨意出現異常當機退出的情況了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69901780/viewspace-2654332/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 線上的一次fullgc排查過程GC
- 記一次自定義starter引發的線上事故覆盤
- 一次JVM記憶體問題導致的線上事故JVM記憶體
- 記一次隱藏很深的 JVM 線上慘案的分析、排查、解決!JVM
- 一次JVM FullGC的背後,竟隱藏著驚心動魄的線上生產事故!【石杉的架構筆記】JVMGC架構筆記
- 一次線上問題的排查解決過程
- 記一次公司JVM堆溢位抽絲剝繭定位的過程JVM
- 記一次公司JVM堆溢位抽繭剝絲定位的過程JVM
- 記錄一次RPC服務有損上線的分析過程RPC
- 記一次透過Memory Analyzer分析記憶體洩漏的解決過程記憶體
- 記一次 Redis Cluster 當機引發的事故Redis
- 記go中一次http超時引發的事故GoHTTP
- 記一次 Composer 問題的解決過程!!
- 記一次線上問題引發的對 Mysql 鎖機制分析MySql
- 【圖片+程式碼】:GCC 連結過程中的【重定位】過程分析GC
- 記一次全民K歌的crash定位過程
- ThreadLocal引起的一次線上事故thread
- 記一次線上崩潰問題的排查過程
- 重大翻車現場,記一次線上事故
- 記一次記憶體溢位問題的排查、分析過程及解決思路記憶體溢位
- 一次線上問題處理過程記錄
- 記錄一次線上OOM情況排查過程OOM
- 記一次線上服務CPU 100%的處理過程
- 一次JVM_OLD區佔用過高、頻繁Full GC的解決過程JVMGC
- 記一次 Java 應用記憶體洩漏的定位過程Java記憶體
- 圖解JVM實驗-觸發FullGC的幾個條件圖解JVMGC
- 記一次低階並嚴重的開發失誤
- 記錄一次排查解決伺服器卡死的過程伺服器
- 一次線上介面超時的排查過程
- 記一次bug解決過程(數字轉化成中文)
- 一次透過dump檔案分析OutOfMemoryError異常程式碼定位過程Error
- 記一次RocketMQ消費非順序訊息引起的線上事故MQ
- 記一次nodejs開發CLI的過程NodeJS
- 記錄一次線上資料圖源本地化操作的過程
- 記一次VMware的崩潰除錯分析過程除錯
- 記一次使用 AetherUpload 影片上傳過程
- 一次sqlldr匯入慢的解決過程SQL
- 詳細記錄一次npm i canvas報錯的解決過程NPMCanvas