你應該從網上看過太多的文章說快取穿透怎麼解決？無非就是布隆過濾器，快取空值什麼的。
但是，更深入的乙個問題，快取空值有沒有問題？如果快取的空值太多怎麼辦？
如果用的redis，那麼太多的空值會不會打爆你的redis？如果用的本地快取，會不會打爆你的記憶體？繼而引發的問題就是還是會打爆你的資料庫。
前置過濾
在資料量不大的情況下直接把所有的key全部從資料庫查出來快取下來，查資料庫之前直接根據key過濾一把，如果不存在就直接返回，不要走資料庫查詢了
根據一定的範圍規則去提前過濾，比如快取的key明確知道在1-10萬的範圍之後，那麼過濾掉在這個範圍之外的請求直接返回就可以了。
當然，很明顯這種簡單的規則過濾適用於資料量不是很大，並且資料不會頻繁發生改變的情況。
布隆過濾器
如果說資料量很大的話，比如有一億個key，使用布隆過濾器就是個更優解。
我們可以每天定時把所有的配置資訊從資料庫中查詢出來構建成bitmap。
如果查詢的位置都是1的話說明key存在，反之只要有乙個0則說明肯定不存在。
使用布隆過濾器的缺點也很明顯，存在一定概率的誤判。當然，既然用了，對於誤判比例、記憶體占用等等問題應該事先評估好。
快取空值
這個是網上說爛的問題，但是快取空值的空值太多明顯也是有問題的，再進一步解決方案就是快速過期。
一般來說，普通的快取的寫法如下，先查快取，如果快取存在則直接返回，如果快取沒有則去資料庫查詢，結果不是空就儲存到快取中。
改進版的寫法就是快取空物件，針對空的資料，設定過期時間，比如10分鐘，快速過期，防止太多的空值問題。
但是這個解決方案仍然有點小問題，就是短暫的資料不一致的問題。
想象一下如果快取的空值這時候實際上已經有值了，那麼在過期時間的這段時間內就可能存在短暫的資料不一致。
快取穿透的問題總結下來就是三點，這三個方式不是說是隔離的解決方案，他們可以結合在一起使用。
首先看資料量，如果資料量很小並且沒有頻繁變更的話，選擇前置過濾的方式，根據具體的業務規則來處理就可以。
如果資料量大的話，可以選擇使用布隆過濾器，但是存在一定概率的誤判。
通過前置的攔截，應該攔截住大部分的流量，避免直接打爆資料庫。
最後，可以使用快取空值並且設定快速過期的方式來作為乙個兜底的方案。
如果還有問題，那麼就是限流、降級了。
redis系列6 快取雪崩 快取擊穿 快取穿透
我們在使用redis快取時候常用方案是先查redis，如果redis有返回，沒有則查資料庫，資料庫查出來後放入redis。快取雪崩是指快取中資料在同一時間大量失效，導致查詢全部落入資料庫。解決方案 資料的過期時間隨機設定，防止同時過期 設定熱點資料永遠不過期。快取擊穿是指某一條熱點資料失效，導致此時...
快取 redis 快取穿透
哪一些因素 考慮使用redis，畢竟 redis 也要增加成本 1 熱點資料 2 讀的成本非常大 3 讀多寫少 4 對資料一致性要求 沒有那麼嚴格 可以出現資料與資料庫不一致 1 秒殺場景 3 物流查詢軌跡 熱點資料 啟用的資料是被快取到redis 當中 快取key 乙個時間點過期的時候，如果快取資...
redis 快取穿透
1 在高併發的場景下本應該查詢快取的，都去查詢資料庫了 情況1例如 if map.isempty else此種情況下在高併發的情況下，多個程序會同時訪問資料庫並向redis放資料 情況1解決的辦法是新增關鍵字 1 synchronized 效率太低了 2 雙重檢測的新增 string userfun...