轉載請注明出處哈:http://carlosfu./blog/2269678

 一,、引出熱點key問題

       我們通常使用 緩存 + 過期時間的策略來幫助我們加速接口的訪問速度，減少了后端負載,，同時保證功能的更新，一般情況下這種模式已經(jīng)基本滿足要求了,。

       但是有兩個問題如果同時出現(xiàn),，可能就會對系統(tǒng)造成致命的危害：

      (1) 這個key是一個熱點key（例如一個重要的新聞，一個熱門的八卦新聞等等）,，所以這種key訪問量可能非常大,。

      (2) 緩存的構建是需要一定時間的。（可能是一個復雜計算,，例如復雜的sql,、多次IO、多個依賴(各種接口)等等）

       于是就會出現(xiàn)一個致命問題：在緩存失效的瞬間,，有大量線程來構建緩存（見下圖）,，造成后端負載加大，甚至可能會讓系統(tǒng)崩潰 ,。

二,、四種解決方案（注釋：第1,2種方法來自Tim Yang博客）

我們的目標是：盡量少的線程構建緩存(甚至是一個) + 數(shù)據(jù)一致性 + 較少的潛在危險，下面會介紹四種方法來解決這個問題：

1. 使用互斥鎖(mutex key): 這種解決方案思路比較簡單,，就是只讓一個線程構建緩存,，其他線程等待構建緩存的線程執(zhí)行完，重新從緩存獲取數(shù)據(jù)就可以了（如下圖）

     如果是單機,，可以用synchronized或者lock來處理,，如果是分布式環(huán)境可以用分布式鎖就可以了（分布式鎖,，可以用memcache的add, redis的setnx, zookeeper的添加節(jié)點操作）,。

     下面是Tim yang博客的代碼，是memcache的偽代碼實現(xiàn)

Java代碼  

1. if (memcache.get(key) == null) {  
2.     // 3 min timeout to avoid mutex holder crash  
3.     if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {  
4.         value = db.get(key);  
5.         memcache.set(key, value);  
6.         memcache.delete(key_mutex);  
7.     } else {  
8.         sleep(50);  
9.         retry();  
10.     }  
11. }  

      如果換成redis,，就是：

Java代碼  

1. String get(String key) {  
2.    String value = redis.get(key);  
3.    if (value  == null) {  
4.     if (redis.setnx(key_mutex, "1")) {  
5.         // 3 min timeout to avoid mutex holder crash  
6.         redis.expire(key_mutex, 3 * 60)  
7.         value = db.get(key);  
8.         redis.set(key, value);  
9.         redis.delete(key_mutex);  
10.     } else {  
11.         //其他線程休息50毫秒后重試  
12.         Thread.sleep(50);  
13.         get(key);  
14.     }  
15.   }  
16. }  

2. "提前"使用互斥鎖(mutex key)：

   在value內(nèi)部設置1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小,。當從cache讀取到timeout1發(fā)現(xiàn)它已經(jīng)過期時候，馬上延長timeout1并重新設置到cache,。然后再從數(shù)據(jù)庫加載數(shù)據(jù)并設置到cache中,。偽代碼如下：

Java代碼  

1. v = memcache.get(key);  
2. if (v == null) {  
3.     if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {  
4.         value = db.get(key);  
5.         memcache.set(key, value);  
6.         memcache.delete(key_mutex);  
7.     } else {  
8.         sleep(50);  
9.         retry();  
10.     }  
11. } else {  
12.     if (v.timeout <= now()) {  
13.         if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {  
14.             // extend the timeout for other threads  
15.             v.timeout += 3 * 60 * 1000;  
16.             memcache.set(key, v, KEY_TIMEOUT * 2);  
17.   
18.             // load the latest value from db  
19.             v = db.get(key);  
20.             v.timeout = KEY_TIMEOUT;  
21.             memcache.set(key, value, KEY_TIMEOUT * 2);  
22.             memcache.delete(key_mutex);  
23.         } else {  
24.             sleep(50);  
25.             retry();  
26.         }  
27.     }  
28. }  

3. "永遠不過期"：

    這里的“永遠不過期”包含兩層意思：

    (1) 從redis上看，確實沒有設置過期時間,，這就保證了,，不會出現(xiàn)熱點key過期問題,，也就是“物理”不過期。

    (2) 從功能上看,，如果不過期,，那不就成靜態(tài)的了嗎？所以我們把過期時間存在key對應的value里,，如果發(fā)現(xiàn)要過期了,，通過一個后臺的異步線程進行緩存的構建，也就是“邏輯”過期

    從實戰(zhàn)看,，這種方法對于性能非常友好,，唯一不足的就是構建緩存時候，其余線程(非構建緩存的線程)可能訪問的是老數(shù)據(jù),，但是對于一般的互聯(lián)網(wǎng)功能來說這個還是可以忍受,。

Java代碼  

1. String get(final String key) {  
2.         V v = redis.get(key);  
3.         String value = v.getValue();  
4.         long timeout = v.getTimeout();  
5.         if (v.timeout <= System.currentTimeMillis()) {  
6.             // 異步更新后臺異常執(zhí)行  
7.             threadPool.execute(new Runnable() {  
8.                 public void run() {  
9.                     String keyMutex = "mutex:" + key;  
10.                     if (redis.setnx(keyMutex, "1")) {  
11.                         // 3 min timeout to avoid mutex holder crash  
12.                         redis.expire(keyMutex, 3 * 60);  
13.                         String dbValue = db.get(key);  
14.                         redis.set(key, dbValue);  
15.                         redis.delete(keyMutex);  
16.                     }  
17.                 }  
18.             });  
19.         }  
20.         return value;  
21.     }  

4. 資源保護：

       之前在緩存雪崩那篇文章提到了netflix的hystrix，可以做資源的隔離保護主線程池,，如果把這個應用到緩存的構建也未嘗不可,。

三、四種方案對比：

      作為一個并發(fā)量較大的互聯(lián)網(wǎng)應用,，我們的目標有3個:

      1. 加快用戶訪問速度,，提高用戶體驗。

      2. 降低后端負載,，保證系統(tǒng)平穩(wěn),。

      3. 保證數(shù)據(jù)“盡可能”及時更新(要不要完全一致，取決于業(yè)務,，而不是技術,。)

      所以第二節(jié)中提到的四種方法，可以做如下比較,，還是那就話：沒有最好,，只有最合適。 

四、總結

   1.  熱點key + 過期時間 + 復雜的構建緩存過程 => mutex key問題

   2. 構建緩存一個線程做就可以了。

   3. 四種解決方案：沒有最佳只有最合適,。

五,、參考文獻：（本文部分代碼和圖來自如下兩篇博客）

1. Memcache mutex設計模式(Tim Yang)
2. cache中的key mutex問題解決及延伸應用
3. 談談Redis的SETNX