以下分享的都跳過了很多坑，包括redis、tomcat環境配置、機器硬體配置等等問題（與線上保持一致，或者硬體效能減配係數，例如線上：8c16g，壓測：4c8g，係數簡單相差2倍），直接把挖掘瓶頸的主要思路搬出檯面。全域性圖預覽
通過對某直播**頁面進行高併發壓測，在apm（pinpoint）監控中發現乙個有趣的地方：
上圖中兩個紅框中的資料（接近10s），相隔大概30分鐘就發生，16:20左右，系統撐不住服務出現異常不可用，懷著好奇的心態，追查方法呼叫的棧，如下圖所示：
該方法耗時多久呢？首先搞清楚call tree裡面的一些概念：
可見這個sql查詢方法耗時14秒多，為什麼呢？apm裡面已經顯示了sql語句，在mysql中執行查詢發現執行時間很快，那麼問題出在**呢？只能繼續深挖！
通過對比同樣的url，請求響應毫秒級的情況下，發現資料如下圖所示：
從redis獲取到資料後，並沒有再執行sql查詢了，通過這個分析，我們決定追蹤**還原真相（不懂**的測試不是好開發）：
可以看到快取失效之後，直接查詢資料庫了
從資料分析來看，sql優化的用處不大，並不是返回了大量資料缺少索引，此次可以跳過。
出現場景：當**併發訪問高，乙個快取如果失效，可能出現多個程序同時查詢db，同時設定快取的情況，如果併發確實很大，這也可能造成db壓力過大，還有快取頻繁更新的問題。
處理方法：對快取查詢加鎖，如果key不存在，就加鎖，然後查db入快取，然後解鎖；其他程序如果發現有鎖就等待，然後等解鎖後返回資料或者進入db查詢。
1、善用監控工具，例如apm，進行鏈路監控、伺服器效能、方法呼叫順序觀察
2、追蹤方法棧和相關日誌
3、深入排查**挖本質
一次快取效能問題排查
以下分享的都跳過了很多坑，包括redis tomcat環境配置 機器硬體配置等等問題 與線上保持一致，或者硬體效能減配係數，例如線上 8c16g，壓測 4c8g，係數簡單相差2倍 直接把挖掘瓶頸的主要思路搬出檯面。全域性圖預覽 通過對某直播 頁面進行高併發壓測，在apm pinpoint 監控中發現...
RocketMQ一次消費效能問題排查 實戰筆記
目錄 一 需求描述 二 問題分析 1.tcpdump網路情況 2.檢視消費執行緒堆疊 3.消費 定位 三 後記 一 需求描述 在容器推廣中，為了測試容器的效能，需要訊息sdk與ecs上在傳送和消費的效能對比 在對比消費效能時，發現容器中的消費效能居然是ecs的2倍。容器併發消費的20個執行緒tps在...
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...