真實案例解析緩存大熱 key 的致命陷阱 - 新聞 詳情

引言

在現代軟件架構中，緩存是提高系統性能和響應速度的重要手段。然而，如果不正確地使用緩存，可能會導致嚴重的線上事故，尤其是緩存的大熱key問題更是老生常談。本文將探討一個常見但容易被忽視的問題：緩存大熱key和緩存擊穿問題。我們將從一個真實案例入手，分析其原因，並提供解決方案和預防措施。

案例描述

某系統在雙十一大促期間，遇到了一個嚴重的線上事故。業務人員在創建一個大型活動，該大型活動由於活動條件和活動獎勵比較多，導致生成的緩存內容非常大。活動上線後，系統就開始出現各種異常告警，核心UMP監控可用率由100%持續下降到20%，系統訪問Redis的調用次數和查詢性能也斷崖式下降，後續更是產生連鎖反應影響了其他多個核心接口的可用率，導致整個系統服務不可用。

原因分析

在這個系統中，為了提高查詢活動的性能，我們開發團隊決定使用Redis作為緩存系統。將每個活動信息作為一個key-value存儲在Redis中。由於業務需要，有時候業務運營人員也會創建一個非常龐大的活動，來支撐雙十一期間的各種玩法。針對這種龐大的活動，我們開發團隊也提前預料到了可能會出現的大key和熱key問題，所以在查詢活動緩存之前增加了一層本地jvm緩存，本地jvm緩存5分鐘，緩存失效後再去回源查詢Redis中的活動緩存，本以為會萬無一失，沒想到最後還是出了問題。
image.png
查詢方法偽代碼

ActivityCache present = activityLocalCache.getIfPresent(activityDetailCacheKey);
if (present != null) {
    ActivityCache activityCache = incentiveActivityPOConvert.copyActivityCache(present);
    return activityCache
}
ActivityCache remoteCache = getCacheFromRedis(activityDetailCacheKey);
activityLocalCache.put(activityDetailCacheKey, remoteCache);
return remoteCache;

查詢活動緩存流程如上圖所示，為什麼加了本地緩存還是出了問題？
這裏其實就存在着第一個緩存陷阱：緩存擊穿問題。首先解釋一下什麼是緩存擊穿；緩存擊穿（Cache Miss）是指在高併發的系統中，如果某個緩存鍵對應的值在緩存中不存在（即緩存失效），那麼所有請求都會直接訪問後端數據庫，導致數據庫的負載瞬間增加，可能會引發數據庫宕機或服務不可用的情況。所以在本次事故里邊，運營人員審批活動上線的一瞬間，活動緩存只是寫入到了Redis緩存中，但是本地緩存還都是空的，所以此時就會有大量請求來同時訪問Redis。
按照以往經驗，Redis緩存都是純內存操作，查詢性能可以滿足大量請求同時查詢活動緩存，就在此時我們卻陷入了第二個緩存陷阱：網絡帶寬瓶頸；Redis的高併發性能毋庸置疑，但是我們卻忽略了一個大key和熱key對網絡帶寬的影響，本次引發問題的大熱key大小達到了1.5M，經過事後瞭解京東Redis對單分片的網絡帶寬也有限流，默認200M，根據換算，該熱key最多隻能支持133次的併發訪問。所以就在活動上線的同一時刻，加上緩存擊穿的影響，迅速達到了Redis單分片的帶寬限流閾值，導致Redis線程進入阻塞狀態，以至於所有的業務服務器都無法查詢Redis緩存成功，最終引發了緩存雪崩效應。

解決方案

為了解決這個問題，我們開發團隊採取了以下措施：

  1. 大key治理：更換緩存對象序列化方法，由原來的JSON序列化調整為Protostuff序列化方式。治理效果：緩存對象大小由1.5M減少到了0.5M。

  2. 使用壓縮算法：在存儲緩存對象時，再使用壓縮算法（如gzip）對數據進行壓縮,注意設置壓縮閾值，超過一定閾值後再進行壓縮，以減少佔用的內存空間和網絡傳輸的數據量。壓縮效果：500k壓縮到了17k。

  3. 緩存回源優化：本地緩存miss後回源查詢Redis增加線程鎖，減少回源Redis併發數量。

  4. 監控和優化Redis配置：定期監控Redis網絡傳輸情況，根據實際情況調整Redis的限流配置，以確保Redis的穩定運行。

治理後業務偽代碼如下：

ActivityCache present = activityLocalCache.get(activityDetailCacheKey, key -> getCacheFromRedis(key));
if (present != null) {                
    return present;
}

         
/**
* 查詢二進制緩存
*
* @param activityDetailCacheBinKey
* @return
*/
private ActivityCache getBinCacheFromJimdb(String activityDetailCacheBinKey) {
    List<byte[]> activityByteList = slaveCluster.hMget(activityDetailCacheBinKey.getBytes(),"stock".getBytes());
    if (activityByteList.get(0) != null && activityByteList.get(0).length > 0) {
        byte[] decompress = ByteCompressionUtil.decompress(activityByteList.get(0));
        ActivityCache activityCache = ProtostuffUtil.deserialize(decompress, ActivityCache.class);
        if (activityCache != null) {
            if (activityByteList.get(1) != null && activityByteList.get(1).length > 0) {
                activityCache.setAvailableStock(Integer.valueOf(new String(activityByteList.get(1))));
            }
            return activityCache;
        }
    }
return null;

預防措施

為了避免類似的問題再次發生，開發團隊採取了以下預防措施：

  1. 設計階段考慮緩存策略：在系統設計階段，充分考慮緩存的使用場景和數據特性，避免盲目使用大key緩存。

  2. 進行壓力測試和性能評估：在上線前，進行充分的壓力測試和性能評估，模擬高併發和大數據量的情況，及時發現和解決潛在問題。

  3. 定期進行系統優化和升級：隨着業務的發展和技術的進步，定期對系統進行優化和升級，引入新的技術和工具來提高系統的性能和穩定性。

結論

緩存大key和熱key是緩存使用中常見的陷阱，千萬不要心存僥倖，否則會引發嚴重的線上事故。通過本文的案例分析和解決方案，我們希望能夠幫助讀者更好地理解和應對這個問題。記住，合理使用緩存是提高系統性能的關鍵，而不是簡單地將所有數據都存儲在緩存中。