一次緩存性能問題排查

概述

如下分享的都跳過了不少坑，包括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查詢。

經驗總結

一、善用監控工具，例如APM，進行鏈路監控、服務器性能、方法調用順序觀察

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

三、深刻排查代碼挖本質

微信公衆號：樂少黑板報