1. 程式人生 > >一次快取效能問題排查

一次快取效能問題排查

概述

以下分享的都跳過了很多坑,包括redis、tomcat環境配置、機器硬體配置等等問題(與線上保持一致,或者硬體效能減配係數,例如線上:8C16G,壓測:4C8G,係數簡單相差2倍),直接把挖掘瓶頸的主要思路搬出檯面。

壓測資料分析

全域性圖預覽


     


通過對某直播觀看頁面進行高併發壓測,在APM(Pinpoint)監控中發現一個有趣的地方:

     

上圖中兩個紅框中的資料(接近10s),相隔大概30分鐘就發生,16:20左右,系統撐不住服務出現異常不可用,懷著好奇的心態,追查方法呼叫的棧,如下圖所示:

     

該方法耗時多久呢?首先搞清楚Call Tree裡面的一些概念:

     

可見這個sql查詢方法耗時14秒多,為什麼呢?APM裡面已經顯示了sql語句,在mysql中執行查詢發現執行時間很快,那麼問題出在哪裡呢?只能繼續深挖!

通過對比同樣的url,請求響應毫秒級的情況下,發現數據如下圖所示:

     

從redis獲取到資料後,並沒有再執行sql查詢了,通過這個分析,我們決定追蹤程式碼還原真相(不懂程式碼的測試不是好開發):

     

     

可以看到快取失效之後,直接查詢資料庫了

解決方案

SQL優化:優先順序低

從資料分析來看,sql優化的用處不大,並不是返回了大量資料缺少索引,此次可以跳過。

快取併發:優先順序高

  出現場景:當網站併發訪問高,一個快取如果失效,可能出現多個程序同時查詢DB,同時設定快取的情況,如果併發確實很大,這也可能造成DB壓力過大,還有快取頻繁更新的問題。
  處理方法:對快取查詢加鎖,如果KEY不存在,就加鎖,然後查DB入快取,然後解鎖;其他程序如果發現有鎖就等待,然後等解鎖後返回資料或者進入DB查詢。



經驗總結

1、善用監控工具,例如APM,進行鏈路監控、伺服器效能、方法呼叫順序觀察

2、追蹤方法棧和相關日誌

3、深入排查程式碼挖本質


微信公眾號:樂少黑板報