redis導致線上服務每隔5分鐘可用率下降
Beautiful Boy
Double Fantasy Stripped Down
John Lennon
00:00/03:50
最近遇到一個線上服務可用率不達100%問題，現象是每5分鐘tp99升高到2000ms，可用率降到95%左右。
首先分析是不是最近有上線引入問題導致，經查最近沒有上線，那就要縮小範圍，目前線上服務存儲均是redis，排查一下是不是有redis集群導致性能下降，經查詢監控是一個redis集群性能下降導致的。
更具體情況是redis mGet tp99由10ms升到2000多ms，問題是定位很具體了，但是處理問題卻沒有想像快，因為一直無法找到一個強相關聯操作情況導致redis集群出現問題，redis節點分片沒有問題、沒有cpu、內存資源高的節點。
前邊遇到過mGet幾十萬數據導致redis阻塞，這次也是有大量定時拉取數據，但是時間對應不上，用這個集群多個業務存在拉取大量數據，但時間對應不上，線上服務因調用量增大，也進行了擴容，但將這些定時器時間調大均未使情況好轉。
同時redis運維方也在分析，是否有集群分片內存cpu過大，導致集群吞吐量下降性能上升。經過調整幾個分片發現對線上效果也不無明顯影響問題依舊。
苦苦分析但就是找不到原因，在查多個服務定時器，時間均對不上，但還是將時間調到了更大，問題依舊得不到解決，不見緩解，比較蛋疼了。
突然林同學說他也在用這個集群，但是只是使用了一個key，並且只是get操作，但時間能對應上，馬上讓他改成13分鐘定時取數據，結果奇蹟發生了，線上多個業務5分鐘沒有發生超時情況，在等如果13分鐘超時再發生，那就基本能斷定問題是由get導致。
等到13分鐘，問題真的發生了，趕緊找出key查詢數據，發現數據有17萬多個值的set組成。問題完全定位，經數據端分析，數據是由下游mq生成一般不到2000，結果有17萬個之多。
到這裡問題基本定位，花費好多時間。
回過頭來看一個極小問題，直接導致線上所有服務均受影響，這就要求我們要時刻小心謹慎，因為每一次讀寫均要多思考，因為一個點回影響一個大的整體。
再有就是一個大value數據，會對redis進行阻塞，影響其他get mGet命令性能。
再有就是對應用技術要有深入認識，不然就很容易發生這種很難定位問題。
對於數據大小一定進行檢查，不然對於集群是破壞性傷害。每一步都要進行檢查，越編程人會越謹慎，因為發現沒注意到的問題最終都會變成一個問題。並且可能還會影響全局。
不斷深入對於原理以及應用研究，不斷思考嘗試以及總結，是能想到避免出現問題的一個比較好的方法。
TAG:互聯網開發者Club |