一次快取效能問題排查

概述

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

壓測資料分析

全域性圖預覽

     

透過對某直播觀看頁面進行高併發壓測，在APM監控中發現一個有趣的地方：

      

上圖中兩個紅框中的資料（接近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、深入排查程式碼挖本質