MemCache緩存雪崩現象
什麼是緩存的雪崩現象
緩存雪崩一般是由某個緩存節點失效,導致其他節點的緩存命中率下降, 緩存中缺失的數據（memcache經典場景，當有一個客戶端的服務請求過來的時候，首先去查memcache，memcache裏面是否緩存過了這個數據，如果沒有這個數據，我們就去數據庫查詢，如果有這個數據，我們就從memcache裏面取出來，然後給它返回到客戶端，這是一個經典的查詢過程，在這個場景中，緩存中缺失的數據，是因爲它的緩存節點失效了，所以缺失的數據將去數據庫查詢。去數據庫查詢.短時間內,造成數據庫服務器崩潰.
重啓 DB,短期又被壓跨,但緩存數據也多一些.
DB 反覆多次啓動多次,緩存重建完畢,DB 才穩定運行.
或者,是由於緩存週期性的失效,比如每 8小時失效一次,那麼每 8小時,將有一個請求”峯值”,
嚴重者甚至會令 DB 崩潰.
Memcache1.png
上圖是之前部門的一個緩存的真實現象，具體是這樣的 緩存的數據設置成爲每8個小時失效一次，導致最終的結果是每8個小時數據庫的壓力就變大一次，每8個小時我們的數據庫就會迎來一次請求的高峯，因爲之前設置的緩存已經失效了。最終導致數據庫的壓力變得非常大。
有什麼好的解決方案
這個沒有完美解決辦法，但可以分析用戶行爲，儘量讓失效時間點均勻分佈。不用把時間都設置成8小時一次，可以把裏面的數據隨機分佈，比如設置成3—8小時隨機的失效，就不會導致數據庫的壓力變得非常大。
即可以這樣：
在緩存失效後，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。 不同的key，設置不同的過期時間，讓緩存失效的時間點儘量均勻。 做二級緩存，A1爲原始緩存，A2爲拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置爲短期，A2設置爲長期，變相使緩存時間均勻一些。