【監控】WebServer入庫與緩存更新代碼優化小計

問題描述：

　　經過WebServer將監控數據入庫到Hbase，在入庫以前須要將指標與ip的列表更新到緩存中，以便前臺頁面隨時選擇查看。前兩天上了一些新用戶致使負載增長，逐漸發現某些用戶的監控場景出現丟數據的狀況，估計Tps要在1w以上。丟數據會致使前段曲線毛刺增長，體驗極差，因此優化WebServer的接收程序須要立馬執行。

 

解決過程：

　　查看GC，YGC頻繁，但FGC基本不多發生，因此丟數據應該不是GC停頓致使的。既然是加了量致使，那麼應該跟處理的性能有關。在看一遍代碼，看出了問題。首先寫入模塊實現的簡單粗暴，當時爲了不多線同步問題，鏈接-寫入-關閉實如今了一個方法體內。另外此時發現CPU也很是的高，這個以前並無在乎（以前是加入了更新緩存的功能，可是CPU升高並無引發在乎），當時覺得是量增大致使，因而先利用nginx加了機器，發現問題並無解決。從新了入庫代碼，單例同步方式將數據添加到Buffer，而後達到必定的閾值刷寫到Hbase。再一看，還沒解決，可是YGC明顯減小。CPU仍是很高，打開日誌查看還有一些由於併發修改致使的異常，定位問題所在，就是更新緩存的模塊出了問題。一看代碼，確實有幾個HashMap沒有加同步，只要一遇到異常，那麼serverlet線程就退出本次操做，因此後續的消息入庫也就無從談起。以前的量級不大，而且不是時刻調用，因此，因爲併發異常致使的崩潰也不是時常發生。再看代碼，代碼寫得很粗暴，因爲是每時每刻都有可能會出現新的數據，因此須要用對緩存的數據作判斷要不要更新。其實這是畫蛇添足，add方法是密等操做，因此你直接add就行，這樣省去不少無謂的比較，判斷。並且每次來數據都更新是徹底不必的，由於新數據（主要是一些新添的監控維度和ip）到來的機率不高，而且實時性不必作到徹底實時，因此採用同步add到本地HashMap，而後達到必定閾值在set到memcached之中，這樣大大減小無謂的比較已經對緩存的操做。另外在清理過時數據時，能夠一天清理一次，判斷是不是下一天的開始，若是是下一天，那麼就在add中先作一下清理操做，而後在add。

 

總結：

　　對於無狀態轉發，nginx是無二之選；

　　近實時的應用出問題要看是否出現FGC停頓，有時候是要命的；（固然此次不是由於這個引發）

　　多線程必定考慮同步問題；儘可能不使用多線程；

　　事先作好批量設計，要清楚各種操做的時耗比例，好比創建鏈接要比一次寫入耗時的多；

　　權衡實時性與吞吐率，通常而言要考慮吞吐率，在能夠忍受的範圍稍微下降一下服務質量，性能會有質的飛躍；

　　冪等操做會省去你不少麻煩的邏輯，也容易提升性能；

　　此次犯錯誤下次就不要再犯，不然對不起你逝去的時間；