一、快取穿透
快取穿透
目的防止訪問（短期內）必然不存在的資料導致請求穿透快取直接打到 db。
原因可能是資料真的不存在，但也可能是第三方惡意構造大量不存在的 id 來衝擊 db。
多種手段結合
1、『儲存empty』思路：儲存乙個 empty 物件到快取對應鍵值，設定乙個較短的過期時間。這樣在快取失效後，還能繼續查詢資料是否存在。
2、必須認真對待（不同業務不同埠的）快取命中率（get_hits/cmd_get * 100）定期監控的結果，認真審視那些命中率低的快取埠，找到命中率低的原因，提出優化方案。
3、『先行校驗』思想：採用
布隆過濾器演算法，將所有可能存在的資料（如所有有效商品的id）雜湊到乙個足夠大的 bitmap 裡，那麼乙個一定不存在的資料會被這個 bitmap 攔截掉，從而避免了對底層儲存系統的查詢壓力。（出處）
二、快取併發
有時候如果**併發訪問高，乙個快取如果失效，可能出現多個程序同時查詢db，同時設定快取的情況，如果併發確實很大，這也可能造成db壓力過大，還有快取頻繁更新的問題。
解決方法是再
快取重建
簡而言之，快取重建時，當多個 client 對同乙個快取資料發起請求時，會在客戶端採用加鎖等待的方式，對同乙個 cachekey 的重建需要獲取到相應的排他鎖才行，只有拿到鎖的 client 才能訪問資料庫重建快取，其他的 client 都需要等待這個拿到鎖的 client 重建好快取後直接讀快取。這樣，對同乙個快取資料，只有一次資料庫重建訪問。但是如果訪問分散比較嚴重，還是會瞬間對資料庫造成非常大的壓力。
三、快取失效
引起這個問題的主要原因還是高併發的時候，平時我們設定乙個快取的過期時間時，可能有一些會設定5分鐘啊，10分鐘這些；併發很高時可能會出在某乙個時間同時生成了很多的快取，並且過期時間都一樣，這個時候就可能引發一當過期時間到後，這些快取同時失效，請求全部**到db，db可能會壓力過重。
其中的乙個簡單方案就時講快取失效
時間分散開，比如我們可以在原有的失效時間基礎上增加乙個隨機值，比如1-5分鐘隨機，這樣每乙個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。
快取集體失效
以下原因都會導致快取集體失效，從而引發系統」抖動「甚至」雪崩「：
系統預熱資料的快取過期時間過於整齊劃一；
快取系統宕機或重啟；
訪問高峰期間種下了一大批快取，過期時間非常接近。
處理手段：
四、分級快取
有些業務場景裡，應該把 db 當成僅是乙個儲存而已，靠分級快取策略來層層抵擋快取失效，不讓請求打到 db。
手段：由遠及近分層建立快取，越靠近前端，快取片段越大（或儲存粒度越大）。
目的：避免系統產生抖動。
減少快取雪崩，防止 db 連線數暴漲、響應變慢，連累前端應用連線數持續高漲、最後宕機。
五、快取永不過期
因為擔心快取失效帶來的系統抖動，所以有些業務場景會讓快取永不過期，資料變化時，由後端負責維護快取資料一致性。
關於IE快取的解決方案
禁止伺服器端快取 response.expires 0 或禁用客戶端快取 htm網頁 asp網頁 response.expires 1 response.expiresabsolute now 1 response.cachecontrol no cache php網頁 header expires...
關於快取穿透 快取併發 快取失效的解決方案
一 快取穿透 二 快取併發 有時候如果 併發訪問高，乙個快取如果失效，可能出現多個程序同時查詢db，同時設定快取的情況，如果併發確實很大，這也可能造成db壓力過大，還有快取頻繁更新的問題。三 快取失效 引起這個問題的主要原因還是高併發的時候，平時我們設定乙個快取的過期時間時，可能有一些會設定5分鐘啊...
關於快取穿透 快取併發 快取失效的解決方案
引起這個問題的主要原因還是高併發的時候，平時我們設定乙個快取的過期時間時，可能有一些會設定5分鐘啊，10分鐘這些 併發很高時可能會出在某乙個時間同時生成了很多的快取，並且過期時間都一樣，這個時候就可能引發一當過期時間到後，這些快取同時失效，請求全部 到db，db可能會壓力過重。前段時間我在網上也剛好...