redis緩存設計及經常使用問題

redis緩存設計及經常使用問題

緩存的收益與成本分析 緩存更新策略的選擇以及使用場景 緩存粒度控制法 穿透問題優化 無底洞問題優化 雪崩問題優化 熱點key重建優化 收益與成本

收益

1. 加速讀寫

2. 下降後端負載 成本

3. 數據不一致性

4. 代碼維護成本

5. 運維成本 緩存更新策略

6. lru，ttl，random，allkey-lru，allkey-random，no-enviction（內存達到最大值時的緩存策略） 2.超時刪除 （設定過時時間） 3.主動更新（用於數據一致性較高） 緩存粒度

7. 所有數據緩存以及部分數據緩存的選擇

8. 思考緩存粒度從幾個維度考慮： 數據通用性，空間佔用比，代碼維護性 一般緩存所有數據 通用性好，代碼維護簡單，可是空間佔用大，而緩存部分數據則相反 穿透問題

緣由：cache miss 後直接請求後端服務，常發生在業務代碼異常，或者大量惡意攻擊致使的

解決方法：

1. 空對象緩存，可是須要注意緩存空間的使用狀況，對空對象緩存時間儘可能要小
2. 布隆過濾器緩存 miss cache 直接返回 不請求後端服務，可是必須有定時程序往緩存中寫數據，適用於數據緩存命中不高的場景 布隆過濾器

用途：快速查詢一個元素是否在一個集合中

入參：失敗率，集合個數

原理：用k個hash函數將結果存在一個位數組中，檢查的時候對比每個位上是不是1 若是全是的話 則說明命中

說明：結果在，有可能不在 結果不在，則必定不在 無底洞問題

表現：集羣增長節點依然性能不佳。耗時有可能還有增長

緣由：客戶端使用mget之類批量獲取key的命令時候，會致使更多的io請求。在redis cluster中 key是分佈在各個slot中，批量操做的話會增長更多的網絡io

解決方式：

1. 相同節點key 合併。總時間 = node + n次命令時間

2. redis 強制將這些key 寫入同一個slot中

性能比較

1. 編程複雜，須要考慮多線程開發的問題
2. 性能最高，維護成本很高，可是容易發生數據傾斜的問題 雪崩問題

表現：在緩存層中服務不可以使用，致使後端服務負載太高，出現宕機的狀況

解決辦法：

1. 緩存高可用架構 （master/slaver，哨兵，cluster）
2. 後端限流降級 （限流3個手段 計數器，漏斗，令牌桶）
3. 提早對業務進行故障演練，正確估計緩存性能，負載狀況 熱點key重建

表現：一般 緩存key+過時時間，能保證絕大部分需求，可是有2種狀況下，這樣的作法會引發性能問題

1. 熱點key 過時重建
2. 重建的邏輯計算至關複雜

緣由。熱點key中 會有大量的線程嘗試重建緩存，致使後端負載過大，甚至引發宕機 解決方式：

1. 引入分佈式鎖 保證同一時間只有一個請求來進行key 重建
2. 設定key 永不過時 直到他變成不是熱點key