一、引出熱點key問題
我們通常使用 緩存 + 過期時間的策略來幫助我們加速接口的訪問速度，減少了后端負載，同時保證功能的更新，一般情況下這種模式已經基本滿足要求了。
但是有兩個問題如果同時出現，可能就會對系統造成致命的危害：
(1) 這個key是一個熱點key（例如一個重要的新聞，一個熱門的八卦新聞等等），所以這種key訪問量可能非常大。
(2) 緩存的構建是需要一定時間的。（可能是一個復雜計算，例如復雜的sql、多次IO、多個依賴(各種接口)等等）
于是就會出現一個致命問題：在緩存失效的瞬間，有大量線程來構建緩存（見下圖），造成后端負載加大，甚至可能會讓系統崩潰 。
二、三種解決方案
我們的目標是：盡量少的線程構建緩存(甚至是一個) + 數據一致性 + 較少的潛在危險，下面會介紹四種方法來解決這個問題：
1、使用互斥鎖(mutex key): 這種解決方案思路比較簡單，就是只讓一個線程構建緩存，其他線程等待構建緩存的線程執行完，重新從緩存獲取數據就可以了（如下圖）
2、“提前”使用互斥鎖(mutex key)
在value內部設置1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當從cache讀取到timeout1發現它已經過期時候，馬上延長timeout1并重新設置到cache。然后再從數據庫加載數據并設置到cache中。
3、 “永遠不過期“
這里的“永遠不過期”包含兩層意思：
(1) 從redis上看，確實沒有設置過期時間，這就保證了，不會出現熱點key過期問題，也就是“物理”不過期。
(2) 從功能上看，如果不過期，那不就成靜態的了嗎？所以我們把過期時間存在key對應的value里，如果發現要過期了，通過一個后臺的異步線程進行緩存的構建，也就是“邏輯”過期
從實戰看，這種方法對于性能非常友好，唯一不足的就是構建緩存時候，其余線程(非構建緩存的線程)可能訪問的是老數據，但是對于一般的互聯網功能來說這個還是可以忍受。
