快取無底洞現象：
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，就落到同乙個節點上
三 快取雪崩現象和無底洞現象
一般是有某個節點失效，導致其他節點的快取命中率下降，快取中缺失的資料去資料庫查詢，短時間內，造成資料庫伺服器崩潰 重啟db，短時間又被壓垮，但快取資料也多了一些，db反覆多次啟動，快取重建完畢，db才穩定執行 案例 乙個上千萬pv的門戶 快取生命週期設定了6小時，當等到6小時快取失效後，之前放到快取...
快取 無底洞優化。
2010年，facebook的memcache節點已經達到了3000個，承載著tb級別的快取資料。但開發和運維人員發現乙個問題，為了滿足業務要求新增了大量新memcache節點，但是發現效能不但沒有好轉反而下降了，當時將這種現象稱為快取的 無底洞 現象。那麼為什麼會產生這種現象呢，通常來說新增節點使...
cdn 快取現象
如圖所示，我在阿里雲物件儲存oss系統中相應的路徑上傳了截圖中的檔案內容，過了一會兒發現這個monaco editor原始碼檔案，不能直接使用，能直接使用的是另外乙個打包過的檔案，內容為 在阿里雲物件儲存系統中刪除舊的檔案內容以後，上傳新的檔案內容，在瀏覽器中通過 網域名稱訪問這個路徑的檔案，發現檔...