一般是有某個節點失效，導致其他節點的快取命中率下降，快取中缺失的資料去資料庫查詢，短時間內，造成資料庫伺服器崩潰
重啟db，短時間又被壓垮，但快取資料也多了一些，db反覆多次啟動，快取重建完畢，db才穩定執行
案例：
乙個上千萬pv的門戶**，快取生命週期設定了6小時，當等到6小時快取失效後，之前放到快取的資料，都轉到db中查詢，這時候，db的壓力急劇上公升，最後導致db崩潰
解決方法：
1.將快取時間設定的更長，等到半夜**訪問量少的時候，進行全部快取的更新
2.將快取時間設定在隨機3-9小時的範圍內，這樣，快取就不會同時失效，可以減少同一時間快取失效量，減少對db的壓力
facebook工作人員反應，facebook在2023年左右，memcached節點已經達到3000個，他們發現了乙個問題：memcached連線頻繁，導致效率下降，於是加memcached節點，新增後發現因為連線頻繁導致的效率問題依然存在，這就被稱為「無底洞現象」。
問題分析：
以使用者為例：user-133-age,user-133-name,user-133-height….n個key,當伺服器增多，133使用者的資訊，也被散落到更多的節點，所以，同樣是訪問個人主頁，得到相同的個人資訊，節點越多，要連線的節點越多，對於memcached的連線數，並沒有隨著節點的增多，而減少，問題出現了
事實上：
nosql與傳統的rdbms並不是水火不容，兩者在某些設計上，是可以相互參考的，對於memcacede、redis這種kv儲存，key的設計，可以參考mysql中表/列的設計
例如：user表，有age、name、height列
例子：對應的key，可以用user:133:age = 23, user:133:name=』lisi』
問題解決方案：
把某一組key，按其共同字首來分布：
例如：user:133-age,user-133-height這兩個key
在用分布式演算法求其節點時，應該以『user-133』來計算，而是已」user-133-age/name』來計算
這樣，兩個關於個人資訊的key，就落到同乙個節點上
快取無底洞現象
快取無底洞現象 facebook工作人員反應，facebook在2010年左右，memcached節點已經達到3000個，他們發現了乙個問題 memcached連線頻繁，導致效率下降，於是加memcached節點，新增後發現因為連線頻繁導致的效率問題依然存在，這就被稱為 無底洞現象 問題分析 以使用...
快取 無底洞優化。
2010年，facebook的memcache節點已經達到了3000個，承載著tb級別的快取資料。但開發和運維人員發現乙個問題，為了滿足業務要求新增了大量新memcache節點，但是發現效能不但沒有好轉反而下降了，當時將這種現象稱為快取的 無底洞 現象。那麼為什麼會產生這種現象呢，通常來說新增節點使...
MemCache快取雪崩現象
memcache快取雪崩現象 什麼是快取的雪崩現象 快取雪崩一般是由某個快取節點失效,導致其他節點的快取命中率下降,快取中缺失的資料 memcache經典場景，當有乙個客戶端的服務請求過來的時候，首先去查memcache，memcache裡面是否快取過了這個資料，如果沒有這個資料，我們就去資料庫查詢...