您好,登錄后才能下訂單哦!
本篇內容主要講解“redis緩存的優點和緩存穿透的解決方法”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“redis緩存的優點和緩存穿透的解決方法”吧!
這里我們主要討論以Redis為代表的基于內存的緩存方案。
提升訪問速度,減少后端如數據庫存儲的時間消耗
減輕后端如數據庫的壓力
任何系統每增加一個組件,在帶來新的特性的同時也必然會帶來額外的復雜度,可以說系統的設計過程就是一個折中的過程。緩存的引入也帶來了一些需要考慮的問題:
數據不一致: 緩存層和存儲層的數據存在著一定的時間窗口的不一致性,時間窗口跟緩存更新策略有關
代碼維護成本: 需要同時處理緩存和存儲層的邏輯
運維成本: 為了保證redis的可用性和并發性,會引入redis sentinel
或redis cluster
等架構,這又增加了系統復雜性和運維難度。
開銷大的復雜運算
加速請求響應
LRU/LFU/FIFO算法
超時剔除
主動更新
低一致性業務建議:最大內存+淘汰策略
高一致性:超時剔除和主動更新
緩存穿透: 是指查詢一個根本不存在的數據, 緩存層和存儲層都不會命中。這會造成存儲層壓力變大。
通常可以在程序中分別統計
總調用數
緩存層命中數
存儲層命中數
如果發現大量存儲層空命中, 可能就是出現了緩存穿透問題。
緩存空對象
占用內存: 原因是為了防止大量空對象(被攻擊) 方案是可以設置比較短的過期時間,讓其自動剔除
數據不一致: 原因是存儲層添加了數據,但是緩存空對象還沒過期, 方案是可以使用消息隊列,
bloomfilter攔截
這種方法適用于數據命中不高、 數據相對固定、 實時性低(通常是數據集較大) 的應用場景, 代碼維護較為復雜,但是緩存空間占用少。
由于緩存集群通常會將key進行hash,然后映射到相應的節點上,造成key的分布與業務無關,批量操作通常需要從不同節點上獲取,相比于單機批量操作只涉及一次網絡操作,分布式批量操作會涉及多次網絡時間。
常見的IO優化思路:
命令本身的優化,例如優化SQL語句等
減少網絡通信次數
pipeline
mget
降低介入成本,例如客戶端使用長連/連接池、NIO等
集群客戶端優化方案
串行IO,把key的請求按照節點分組,然后依次處理
并行IO,把key的請求按照節點分組,然后并行處理
hash_tag實現, 可以將多個key強制分配到一個節點上,它的操作時間=1此網絡時間+n次命令時間,性能最高,但是數據維護成本高,數據易傾斜
雪崩定義:由于緩存層承載著大量請求,有效地保存了存儲層,但是如果緩存層由于某些原因不能提供服務,于是所有的請求都會到達存儲層,存儲層的調用會暴增。
說到底就是緩存扛不住了,把壓力沖擊到了存儲層。
保證緩存層服務高可用性,redis提供了Redis Sentinel
和Redis Cluster
依賴隔離組件為后端限流并降級,降級機制,如Hystrix
提前演練,項目上線前,演練緩存層宕掉后,應用及后端的負載情況以及可能出現的問題。
緩存+過期時間的策略既可以加速數據讀寫,又保證數據的定期更新,這種模式基本能夠滿足絕大部分需求。但有兩個問題:
熱點key,并發量非常大
重建緩存不能在短時間完成(長時生成緩存)
互斥鎖
永遠不過期,但是重建期間會有不一致問題
到此,相信大家對“redis緩存的優點和緩存穿透的解決方法”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。