快取一般作為rds的前置元件，將常用的資源快取，用來減少rds的讀取壓力，也是諸多系統常用的一種方案，如果允許訪問快取失敗直接訪問資料庫，然後再將資料回寫到快取中，那麼就會存在快取擊穿的問題，
快取擊穿：快取中的資料未被命中，進而請求直接對資料庫進行查詢，當大量的類似查詢瞬間出現，就會出現資料庫的壓力**甚至引起資料庫的雪崩，本質就是一種快取失效引發的極端問題
如何應對這種情況？
在很多面試過程中碰到這樣的問題，給出答案：不給快取擊穿的機會
首先不允許跨過快取直接訪問資料庫，在快取中及認為資料可以被訪問，否則則認為訪問的資料不存在，
接下來就是rds和快取的同步問題，保證資料最終會呈現給使用者，但是有延遲，功能的延遲和系統雪崩的風險選擇，個人比較傾向於後者，
這種方案將資料的查詢完全依賴快取，一旦快取掛掉，基本系統也就over了，這就依賴快取的高可用部署了，採用集群或者多集群的方式，提高系統的可用性，剩下的就是和rds一樣的問題，比如防攻擊，資料切片等
另外還有一種方案，加鎖的方式，對於同乙個key進行枷鎖，當key 不命中的時候，需要去資料庫中去查詢然後回寫到快取中，查詢已經回寫的操作進行加鎖，粗暴一點 可以用synchronized直接加鎖，最壞的情況，jvm中，某個key的請求的請求 全部block，另外可以用分布式鎖的方案，當發現key不命中時向redis中新增乙個lock_key，新增方式使用setnx指令，這樣同乙個key的請求只有乙個成功，設定成功的請求，進行查詢回寫操作，設定失敗的請求，建議直接進行返回，不要等待，比較乙個伺服器的連線數是有限制的，如果太多請求等待的話 會影響其他的正常業務
redis快取擊穿問題
1.讀模式，如何讀取乙個資料，應該遵循先從快取中讀取，如果快取中沒有，再在資料庫讀取，如果在資料庫查到資料則再放到快取中，並返回 2.寫模式，如何保證快取中的資料和資料庫中的資料是一致的 可以使用雙寫模式或失效模式 指查詢乙個一定不存在的資料，由於快取是不命中的，將會查詢資料庫，但是資料庫也無此記錄...
快取穿透 快取擊穿 快取雪崩問題
快取穿透 快取穿透，是指查詢乙個資料庫一定不存在的資料正常的使用快取流程大致是，資料查詢先進行快取查詢，如果 key 不存在或者 key 已經過期，再對資料庫進行查詢，並把查詢到的物件，放進快取。如果資料庫查詢物件為空，則不放進快取，就會每次都去查詢資料庫，而每次查詢都是空，每次又都不會進行快取。假...
快取穿透，快取雪崩，快取擊穿解決方案分析
目錄前言 快取穿透 快取雪崩 快取擊穿 總結 設計乙個快取系統，不得不要考慮的問題就是 快取穿透 快取擊穿與失效時的雪崩效應。快取穿透是指查詢乙個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失...