快取穿透
快取穿透：去快取查詢沒有命中資料 而進mysql查詢資料
不能避免低頻快取穿透,避免高頻的快取穿透
第一種
id=-1
黑客通過一個固定非法請求去攻擊資料庫
可採用null再次快取的解決方案
第二種
id=uuid
過濾器
在redis和mysql之間安裝一個過濾器
（1） 解決過濾器記憶體緊張的問題
布隆演算法 ：通過一定的錯誤率換取空間
通過一個bit陣列來標識
1 hash的範圍[0,length-1]
2 計算出來hash值 足夠雜湊
3 陣列初始化全是0
4 比如id=10 計算出hash值=5 那麼標識bit陣列下標等於5的標記為1
5 存在hash碰撞
6 減少hash配置 多用幾個hash函式 同時標記
7 弊端刪除資料 （bit資料裡的值1 不能隨便改成0）
解決方案 ： 搞一個計數器二位陣列 如果計數器為可以刪除
hash 錯誤率
布隆演算法說資料存在，那麼實際可能不存在（hash碰撞）
說資料不存在，那麼肯定不存在
快取雪崩
快取層在 在某一個時刻（無法訪問）導致大量的請求大向mysql資料庫
可能發生快取雪崩的原因
（1） redis中快取的資料有效期一致
解決方案： 對不同的資料設定不同的有效期（隨機有效期）
（2） redis資料庫掛掉了
解決方案：分散式快取
分散式快取
傳統的演算法 hash取模 資料相對平均
缺點 ： 不利於叢集擴充套件
redis叢集的hash一致性演算法（解決叢集的擴充套件）
hash一致性也有弊端 資料傾斜
增加虛擬節點 （redis槽 16384）
快取擊穿（一般公司不解決）
快取擊穿 ： redis只快取一條資料
解決方案分散式鎖
弊端： 會出死鎖
解決方案： 監聽鎖的時間 超出設定的timeout 幹掉鎖
新的問題： timeout設定多長 ？？？
1s 很短 發生了GC掛了 下一個程式搶到了 （2個程式打架）
10s
1年（哈哈） 下一個程式等待1年-1s
zookeeper實現分散式鎖 臨時有序的節點
其實並不需要這麼繁瑣 ： mysql 查來放進redis快取就 OK 了
總結 快取擊穿和快取雪崩本身都是快取穿透
快取擊穿和快取雪崩是快取穿透的特殊表現
本作品採用《CC 協議》，轉載必須註明作者和本文連結