redis快取常見問題及解決方案

快取雪崩

當快取伺服器重啟或者大量快取集中在某乙個時間段失效，這樣在失效的時候，會給後端系統帶來很大壓力。導致系統崩潰。

解決方案：

在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個線程查詢資料和寫快取，其他執行緒等待。

做二級快取，a1為原始快取，a2為拷貝快取，a1失效時，可以訪問a2，a1快取失效時間設定為短期，a2設定為長期。

將快取失效時間分散開，比如可以在原有的失效時間基礎上增加乙個隨機值，比如 1-5 分鐘隨機，這樣每乙個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。

快取穿透

一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢（比如 db）。一些惡意的請求會故意查詢不存在的key,請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。

解決方案：

對查詢結果為空的情況也進行快取，快取時間設定短一點，或者該key對應的資料insert了之後清理快取。

布隆過濾器：將所有可能存在的資料雜湊到乙個足夠大的 bitmap 中，乙個一定不存在的資料會被這個 bitmap 攔截掉，從而避免了對 db 的查詢。

快取擊穿

對於設定了過期時間的 key，快取在某個時間點過期的時候，恰好這時間點對這個 key 有大量的併發請求過來，這些請求發現快取過期一般都會從後端 db 載入資料並回設到快取，這個時候大併發的請求可能會瞬間把 db 壓垮。

解決方案：

永遠不過期：物理不過期，但邏輯過期（後台非同步執行緒去重新整理）。

使用互斥鎖：當快取失效時，不立即去 load db，先使用如 redis 的 setnx 去設置乙個互斥鎖，當操作成功返回時再進行 load db 的操作並回設快取，否則重試 get 快取的方法。

public string get
(key)
else
}else
}