Redis緩存穿透、擊穿、雪崩等場景解決方案
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
一、緩存穿透定義:查詢一個不存在的數據,Mysql查詢不到數據也不會直接寫入緩存,導致每次請求都要查數據庫 兩個解決方案:
舉例說明:根據文章id查詢文章,請求路徑如下: 正常緩存流程:根據id到redis中爬取數據,若找到數據則返回結果;若redis中未找到,再到數據庫中查找,將結果返回,返回前需將數據庫中查到的數據存儲于redis中 緩存穿透是查詢一個不存在的數據,Mysql查詢不到數據也不會直接寫入緩存,導致每次請求都要查數據庫。導致這種情況一般是由于系統被惡意攻擊,請求路徑被獲取后制造假id(0、復數、很大的值),瘋狂沖擊數據庫,數據庫并發并不高,請求達到一定量就會造成宕機 關于布隆過濾器 二、緩存擊穿定義:給某個key設置過期時間,當key過期時,剛好這個時間點key有大量的并發請求,這些并發請求可能瞬間把DB壓垮。 雖然我們再查詢時把數據同步到redis,但可能在緩存重建時,存入的是多個表匯總的結果,可能需要分組統計花費較長的時間,比如花費了50毫秒,這時若有大量請求數據庫是承受不住的。 兩個解決方案:
互斥鎖:強一致性、性能差 邏輯過期:高可用、性能優 三、緩存雪崩定義:指同一時段大量緩存key同時失效或Redis服務宕機,導致大量請求達到數據庫造成巨大壓力。 解決方案
降級可作為系統的保底策略,適用于穿透、擊穿、雪崩 四、雙寫一致性定義:當修改了數據庫數據也要更新緩存的數據,保持緩存和數據庫的數據一致
先刪除緩存,還是先修改數據庫? 先刪除緩存,再修改數據庫
修改數據庫數據前被其他線程寫入緩存,導致緩存與數據庫數據不一致 先修改操作數據庫,再刪除緩存
線程1得到的返回的結果寫入緩存,與線程2更新的數據庫數據對不上 所以不管先刪除緩存,還是先修改數據庫都會出現臟數據,應該采取延遲雙刪的方法,即刪除兩次緩存,可以降低臟數據的出現。延遲刪除是因為數據庫是主存模式,延遲刪除讓主節點把數據同步到從節點,但延遲刪除也只是控制了一部分臟數據的風險,由于延遲時間不好確認,也有臟數據的風險,做不到絕對的強一至。 如何保持強一致性?
強一致,性能低 一般存入緩存的數據都是讀多寫少,用讀寫鎖來進行控制
具體代碼操作:
利用異步通知解決數據同步問題
它是基于mysql的主從同步實現 五、持久化兩種方式:RDB、AOF
將內存中的數據存到磁盤中,當redis實例故障重啟后,從磁盤讀取快照文件,恢復數據 人工主動備份: redis內部有觸發RBG的機制,可以在redis.conf文件中找到
六、數據過期策略Redis過期刪除策略:惰性刪除 + 定期刪除兩種策略配合使用
定義:訪問key時再判斷是否過期,過期則刪除,反之返回key ? ?優點:對CPU友好
定義:每隔一段時間,會從一定數量的數據庫中取出一定數量的隨機key進行檢查,并刪除其中的過期key(隨之時間推一會遍歷所有key,把所有過期key刪除)
優點:可通過限制刪除操作執行時長和頻率減少刪除操作對CPU的影響,另外定期刪除能有效釋放過期鍵占用的內存 七、數據淘汰策略定義:當redis內存不足想添加新key,會按照某種規則將內存數據刪除,這種數據刪除規則被成為內存的淘汰策略
使用建議 轉自https://www.cnblogs.com/PandaVerse/p/18399430 該文章在 2025/5/15 9:52:50 編輯過 |
關鍵字查詢
相關文章
正在查詢... |