Redis緩存設計

緩存更新策略

策略	一致性	維護成本
LRU、LRF、FIFO	最差	低
超時剔除	較差	較低
主動更新	強	高

低一致性業務：最大內存和淘汰策略的方式，maxmemory-policy

高一致性業務：超時剔除和主動更新

緩存穿透

解決緩存穿透	適用場景	維護成本
緩存空對象	數據命中不高，數據頻繁變化實時性高	代碼維護簡單，須要過多的緩存空間，數據不一致
布隆過濾器	數據命中不高、數據相對固定、實時性低	代碼維護複雜，緩存佔用空間小

緩存空對象：針對該類對象需設置較短過時時間。

布隆過濾器：將存在的key用布隆過濾器保存起來，若是過濾器認爲該信息不存在，那麼不會訪問存儲層。該方法適用於數據命中不高的場景

緩存雪崩

緩存服務器宕機了，或在某一時刻緩存同時到期，致使大量的流量打向後端存儲

1. 保證緩存層的高可用性
2. 依賴隔離組件爲後端限流並降級

熱點key重建優化

開發人員使用「緩存+過時時間」的策略既能夠加速數據讀寫，又保證數據的按期更新，這種模式基本可以知足絕大
部分需求。可是有兩個問題若是同時出現，可能就會對應用形成致命的危害：
當前key是一個熱點key（例如一個熱門的娛樂新聞），併發量很是大。
重建緩存不能在短期完成，多是一個複雜計算，例如複雜的SQL、屢次IO、多個依賴等。在緩存失效的瞬
間，有大量線程來重建緩存，形成後端負載加大，甚至可能會讓應用崩潰。
要解決這個問題也不是很複雜，可是不能爲了解決這個問題給系統帶來更多的麻煩，因此須要制定以下目
標：
減小重建緩存的次數
數據儘量一致
較少的潛在危險
①互斥鎖：此方法只容許一個線程重建緩存，其餘線程等待重建緩存的線程執行完，從新從緩存獲取數據即
可。

②永遠不過時

永遠不過時」包含兩層意思： 從緩存層面來看，確實沒有設置過時時間，因此不會出現熱點key過時後產生的問題，也就是「物理」不過時。 從功能層面來看，爲每一個value設置一個邏輯過時時間，當發現超過邏輯過時時間後，會使用單獨的線程去構建緩存。
從實戰看，此方法有效杜絕了熱點key產生的問題，但惟一不足的就是重構緩存期間，會出現數據不一致的狀況，這取決於應用方是否容忍這種不一致。