一次緩存性能問題排查

概述

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

創(chuàng)新互聯(lián)的團(tuán)隊(duì)成員不追求數(shù)量、追求質(zhì)量。我們經(jīng)驗(yàn)豐富并且專業(yè)，我們之間合作時就好像一個人，協(xié)同一致毫無保留。成都創(chuàng)新互聯(lián)公司珍視想法，同時也看重過程轉(zhuǎn)化帶來的沖擊力和影響力，在我們眼中，任何細(xì)節(jié)都不容小覷。一直致力于為企業(yè)提供從申請域名、網(wǎng)站策劃、網(wǎng)站設(shè)計、成都做商城網(wǎng)站、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個性化軟件開發(fā)等基于互聯(lián)網(wǎng)的全面整合營銷服務(wù)。

壓測數(shù)據(jù)分析

全局圖預(yù)覽

cdn.xitu.io/2018/11/29/1675ebca0b8bfcb2?w=1919&h=880&f=png&s=125839">

     

通過對某直播觀看頁面進(jìn)行高并發(fā)壓測，在APM（Pinpoint）監(jiān)控中發(fā)現(xiàn)一個有趣的地方：

     

上圖中兩個紅框中的數(shù)據(jù)（接近10s），相隔大概30分鐘就發(fā)生，16:20左右，系統(tǒng)撐不住服務(wù)出現(xiàn)異常不可用，懷著好奇的心態(tài)，追查方法調(diào)用的棧，如下圖所示：

     

該方法耗時多久呢？首先搞清楚Call Tree里面的一些概念：

     

可見這個sql查詢方法耗時14秒多，為什么呢？APM里面已經(jīng)顯示了sql語句，在MySQL中執(zhí)行查詢發(fā)現(xiàn)執(zhí)行時間很快，那么問題出在哪里呢？只能繼續(xù)深挖！

通過對比同樣的url，請求響應(yīng)毫秒級的情況下，發(fā)現(xiàn)數(shù)據(jù)如下圖所示：

     

從redis獲取到數(shù)據(jù)后，并沒有再執(zhí)行sql查詢了，通過這個分析，我們決定追蹤代碼還原真相（不懂代碼的測試不是好開發(fā)）：

     

     

可以看到緩存失效之后，直接查詢數(shù)據(jù)庫了

解決方案

SQL優(yōu)化：優(yōu)先級低

從數(shù)據(jù)分析來看，sql優(yōu)化的用處不大，并不是返回了大量數(shù)據(jù)缺少索引，此次可以跳過。

緩存并發(fā)：優(yōu)先級高

出現(xiàn)場景：當(dāng)網(wǎng)站并發(fā)訪問高，一個緩存如果失效，可能出現(xiàn)多個進(jìn)程同時查詢DB，同時設(shè)置緩存的情況，如果并發(fā)確實(shí)很大，這也可能造成DB壓力過大，還有緩存頻繁更新的問題。
處理方法：對緩存查詢加鎖，如果KEY不存在，就加鎖，然后查DB入緩存，然后解鎖；其他進(jìn)程如果發(fā)現(xiàn)有鎖就等待，然后等解鎖后返回數(shù)據(jù)或者進(jìn)入DB查詢。

經(jīng)驗(yàn)總結(jié)

1、善用監(jiān)控工具，例如APM，進(jìn)行鏈路監(jiān)控、服務(wù)器性能、方法調(diào)用順序觀察

2、追蹤方法棧和相關(guān)日志

3、深入排查代碼挖本質(zhì)

微信公眾號：樂少黑板報

網(wǎng)站欄目：一次緩存性能問題排查
本文地址：http://muchs.cn/article12/ghsogc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、品牌網(wǎng)站設(shè)計、全網(wǎng)營銷推廣、網(wǎng)站設(shè)計公司、Google、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)