緩存穿透問題

 一. 緩存穿透 (請求數據緩存大量不命中):

    緩存穿透是指查詢一個一定不存在的數據,由於緩存不命中,並且出於容錯考慮, 如果從存儲層查不到數據則不寫入緩存,這將導致這個不存在的數據每次請求都要到存儲層去查詢,失去了緩存的意義。

    例如:下圖是一個比較典型的cache-storage架構,cache(例如memcache, redis等等) + storage(例如mysql, hbase等等)架構,查一個壓根就不存在的值, 如果不做兼容,永遠會查詢storage。

二. 危害:

     對底層數據源(mysql, hbase, http接口, rpc調用等等)壓力過大,有些底層數據源不具備高併發性。下載

     例如mysql一般來說單臺能夠扛1000-QPS就已經很不錯了(別說你的查詢都是select * from table where id=xx 以及你的機器多麼牛逼,那就有點矯情了)

     例如他人提供的一個抗壓性很差的http接口,可能穿透會擊潰他的服務。

     

三. 如何發現:

   我們可以分別記錄cache命中數, storage命中數,以及總調用量,如果發現空命中(cache,storage都沒有命中)較多,可能就會在緩存穿透問題。下載

   注意:緩存本身的命中率(例如redis中的info提供了類似數字,只代表緩存本身)不代表storage和業務的命中率。

   

四. 產生原因以及業務是否允許?

    產生原因有很多:可能是代碼本身或者數據存在的問題造成的,也很有可能是一些惡意***、爬蟲等等(因爲http讀接口都是開放的)

    業務是否允許:這個要看做的項目或者業務是否允許這種情況發生,比如做一些非實時的推薦系統,假如新用戶來了,確實沒有他的推薦數據(推薦數據通常是根據歷史行爲算出),這種業務是會發生穿透現象的,至於業務允不允許要具體問題具體分析了。下載

 

五. 解決方法:

解決思路大致有兩個,如下表。下面將分別說明

解決緩存穿透適用場景維護成本
緩存空對象

1. 數據命中不高

2. 數據頻繁變化實時性高

1.代碼維護簡單

2.需要過多的緩存空間

3. 數據不一致

bloomfilter或者壓縮filter提前攔截

1. 數據命中不高

2. 數據相對固定實時性低

1.代碼維護複雜

2.緩存空間佔用少

       1. 緩存空對象下載

         

        (1). 定義:如上圖所示,當第②步MISS後,仍然將空對象保留到Cache中(可能是保留幾分鐘或者一段時間,具體問題具體分析),下次新的Request(同一個key)將會從Cache中獲取到數據,保護了後端的Storage。

        (2) 適用場景:數據命中不高,數據頻繁變化實時性高(一些亂轉業務)

        (3) 維護成本:代碼比較簡單,但是有兩個問題:

             第一是空值做了緩存,意味着緩存系統中存了更多的key-value,也就是需要更多空間(有人說空值沒多少,但是架不住多啊),解決方法是我們可以設置一個較短的過期時間。

             第二是數據會有一段時間窗口的不一致,假如,Cache設置了5分鐘過期,此時Storage確實有了這個數據的值,那此段時間就會出現數據不一致,解決方法是我們可以利用消息或者其他方式,清除掉Cache中的數據。

        (4) 僞代碼:

Java代碼  下載

  1. package com.carlosfu.service;  

  2.   

  3. import org.apache.commons.lang.StringUtils;  

  4.   

  5. import com.carlosfu.cache.Cache;  

  6. import com.carlosfu.storage.Storage;  

  7.   

  8. /** 

  9.  * 某服務 

  10.  *  

  11.  * @author carlosfu 

  12.  * @Date 2015-10-11 

  13.  * @Time 下午6:28:46 

  14.  */  

  15. public class XXXService {  

  16.   

  17.     /** 

  18.      * 緩存 

  19.      */  

  20.     private Cache cache = new Cache();  

  21.   

  22.     /** 

  23.      * 存儲 

  24.      */  

  25.     private Storage storage = new Storage();  

  26.   

  27.     /** 

  28.      * 模擬正常模式 

  29.      * @param key 

  30.      * @return 

  31.      */  

  32.     public String getNormal(String key) {  

  33.         // 從緩存中獲取數據  

  34.         String cacheValue = cache.get(key);  

  35.         // 緩存爲空  

  36.         if (StringUtils.isBlank(cacheValue)) {  

  37.             // 從存儲中獲取  

  38.             String storageValue = storage.get(key);  

  39.             // 如果存儲數據不爲空,將存儲的值設置到緩存  

  40.             if (StringUtils.isNotBlank(storageValue)) {  

  41.                 cache.set(key, storageValue);  

  42.             }  

  43.             return storageValue;  

  44.         } else {  

  45.             // 緩存非空  

  46.             return cacheValue;  

  47.         }  

  48.     }  

  49.   

  50.   

  51.     /** 

  52.      * 模擬防穿透模式 

  53.      * @param key 

  54.      * @return 

  55.      */  

  56.     public String getPassThrough(String key) {  

  57.         // 從緩存中獲取數據  

  58.         String cacheValue = cache.get(key);  

  59.         // 緩存爲空  

  60.         if (StringUtils.isBlank(cacheValue)) {  

  61.             // 從存儲中獲取  

  62.             String storageValue = storage.get(key);  

  63.             cache.set(key, storageValue);  

  64.             // 如果存儲數據爲空,需要設置一個過期時間(300秒)  

  65.             if (StringUtils.isBlank(storageValue)) {  

  66.                 cache.expire(key, 60 * 5);  

  67.             }  

  68.             return storageValue;  

  69.         } else {  

  70.             // 緩存非空  

  71.             return cacheValue;  

  72.         }  

  73.     }  

  74.   

  75. }  

 

2. bloomfilter或者壓縮filter(bitmap等等)提前攔截下載

        (1). 定義:如上圖所示,在訪問所有資源(cache, storage)之前,將存在的key用布隆過濾器提前保存起來,做第一層攔截, 例如: 我們的推薦服務有4億個用戶uid, 我們會根據用戶的歷史行爲進行推薦(非實時),所有的用戶推薦數據放到hbase中,但是每天有許多新用戶來到網站,這些用戶在當天的訪問就會穿透到hbase。爲此我們每天4點對所有uid做一份布隆過濾器。如果布隆過濾器認爲uid不存在,那麼就不會訪問hbase,在一定程度保護了hbase(減少30%左右)。下載

            

        (2) 適用場景:數據命中不高,數據相對固定實時性低(通常是數據集較大)

        (3) 維護成本:代碼維護複雜, 緩存空間佔用少

              第一是空值做了緩存,意味着緩存系統中存了更多的key-value,也就是需要更多空間(有人說空值沒多少,但是架不住多啊),解決方法是我們可以設置一個較短的過期時間。

              第二是數據會有一段時間窗口的不一致,假如,Cache設置了5分鐘過期,此時Storage確實有了這個數據的值,那此段時間就會出現數據不一致,解決方法是我們可以利用消息或者其他方式,清除掉Cache中的數據。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章