掃描下方海報二維碼,試聽課程:
面試
(課程詳細大綱,請參見文末)算法
「 這篇文章給你們聊一次線上生產系統事故的解決經歷,其背後表明的是線上生產系統的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寫機制在代碼層面大概是什麼樣子的。
上面就是通過大幅精簡後的代碼,不過核心的意思是表達清晰了。你們能夠仔細看兩遍,其實仍是很容易弄懂的。
這段代碼其實含義很簡單,說白了就是異步開啓線程發送數據給系統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發生的狀況下,也不會隨意出現異常宕機退出的狀況了。
END
《21天互聯網Java進階面試訓練營(分佈式篇)》詳細目錄,掃描圖片末尾的二維碼,試聽課程