一.緩存雪崩現象 緩存雪崩一般是由某個緩存節點失效,導致其他節點的緩存命中率下降, 緩存中缺失的數據去資料庫查詢,短時間內造成資料庫伺服器崩潰, 重啟DB短期又被壓跨,但新數據的緩存也更新一些,DB反覆多次啟動多次,緩存重建完畢,DB才穩定運行,或者是由於緩存周期性的失效,比如緩存失效周期相同,在一 ...
一.緩存雪崩現象
緩存雪崩一般是由某個緩存節點失效,導致其他節點的緩存命中率下降, 緩存中缺失的數據去資料庫查詢,短時間內造成資料庫伺服器崩潰,
重啟DB短期又被壓跨,但新數據的緩存也更新一些,DB反覆多次啟動多次,緩存重建完畢,DB才穩定運行,或者是由於緩存周期性的失效,比如緩存失效周期相同,在一個時間點緩存同時失效,將有一個請求”峰值”, 嚴重者甚至會令DB崩潰
解決方案:把緩存設置為不同的生命周期,這樣不同時失效,把工作分擔到各個時間點上去,也可以自己寫腳本，放到業務比較空閑的時候自己刷新建立緩存，比如放到凌晨時分
二.緩存的無底洞現象 multiget-hole
memcached的節點非常多,memcached 連接頻率、效率下降,於是增加 memcached 節點, 發現因為連接頻率導致的問題仍然存在稱之為”無底洞現象”
以用戶信息為例: 一個用戶有很多的信息,user1-age, user1-name,user1-height ,當伺服器增多,用戶的信息也被散落在更多的節點,user1-age在一個節點,user1-name在第二個節點上,user1-height在第三個節點上,
這時候同樣是獲取這個人的用戶信息就要連接多個節點,節點越多要連接的節點也越多. 對於memcached的連接數,並沒有隨著節點的增多,而降低於是問題出現
解決方案:在保存用戶信息的時候key鍵使用共同的首碼進行保存,如使用user1作為鍵,而不是user1-age為一個鍵,user1-name為一個鍵...
三.緩存穿透現象
在按照key去緩存查詢一個一定不存在的數據,由於緩存未命中需要從資料庫查詢,資料庫未查到數據也不做緩存,並且對該key併發請求量很大,就會對系統造成很大的壓力,這就是緩存穿透
解決方案:當查詢返回的數據為空時,我們仍然把這個空結果進行緩存並設置一個相對較短的生命周期
四.永久數據被踢現象
緩存數據時已經設為永久有效,卻莫名其妙的丟失了,這種現象是因為memcache的惰性刪除機制,即LRU最近最少使用刪除機制,
當某個單元被請求時,memcache維護一個計數器,通過計數器來判斷最近最少被使用的是誰就把誰踢出,即使是永久有效的數據,如果一直沒有被使用,而庫又滿了的情況下,就會把這個永久數據踢出
解決方案:永久數據和非永久數據分開存放
