您好,登錄后才能下訂單哦!
本篇內容主要講解“Redis擊穿穿透雪崩產生原因是什么及怎么解決”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Redis擊穿穿透雪崩產生原因是什么及怎么解決”吧!
大家都知道,計算機的瓶頸之一就是IO,為了解決內存與磁盤速度不匹配的問題,產生了緩存,將一些熱點數據放在內存中,隨用隨取,降低連接到數據庫的請求鏈接,避免數據庫掛掉。需要注意的是,無論是擊穿還是后面談到的穿透與雪崩,都是在高并發前提下,比如當緩存中某一個熱點key失效。
有兩個主要原因:
1、Key過期;
2、Key被頁面置換淘汰。
對于第一個原因是因為在Redis中,Key有過期時間,如果某一個時刻(假如商城做活動,零點開始)key失效,那么零點之后對某一個商品查詢請求將全都壓到數據庫上,導致數據庫崩。
對于第二個原因,因為內存是有限的,要時時刻刻緩存新的數據,淘汰舊的數據,所以在一定的頁面置換策略(常見頁面置換算法圖解)中,淘汰數據,如果某些商品做活動之前無人問津,勢必會被淘汰。
正常的處理請求如圖:
由于key過期在所難免,高流量來到Redis時,根據Redis的單線程特性,可以認為任務是在隊列里依次執行的,當請求到達Redis發現Key過期時,進行一個操作:設置鎖。
這個流程大概如下:
請求到達Redis,發現Redis Key過期,查看有沒有鎖,沒有鎖的話回到隊列后面排隊
設置鎖,注意,這兒應該是setnx(),而不是set(),因為可能有其他線程已經設置鎖了
獲取鎖,拿到鎖了就去數據庫取數據,請求返回后釋放鎖。
但是引出了一個新的問題,如果拿到鎖去拿數據的請求然后掛了怎么辦?也就是鎖沒有釋放,其他進程都在等鎖,解決辦法是:
對鎖設置一個過期時間,如果到達了過期時間還沒釋放就自動釋放,問題又來了,鎖掛了好說,但是如果是鎖超時呢?也就是在設定的時間里數據沒有取出來,但是鎖由過期了,常見的思路是,鎖過期時間值遞增,但是想想不靠譜,因為第一個請求可能超時,如果后面的也超時呢,接連多次超時之后,鎖過期時間值勢必特別大了,這樣做弊端太多。
另外一個思路是,再開啟一個線程,進行監控,如果取數據的線程沒有掛的話,就適當延遲鎖的過期時間。
穿透主要原因是很多請求都在訪問數據庫不存在的數據,例如一個賣書的商城一直被請求查詢茶葉產品,由于Redis緩存主要是用來緩存熱點數據,對于數據庫都不存在的數據,是沒法緩存的,這種異常流量就會直接到達數據庫并且返回"沒有"的查詢結果。
應對這種請求,處理辦法是對訪問請求加一層過濾器,例如布隆過濾器、增強版布隆過濾器、布谷鳥過濾器。
除了布隆過濾器,可以增加一些參數檢驗,例如數據庫數據id一般都是遞增的,如果請求 id = -10 這種參數,勢必繞過Redis,避免這種情況,可以對用戶真實性檢驗等操作。
雪崩,和擊穿類似,不同的是擊穿是一個熱點Key某時刻失效,而雪崩是大量的熱點Key在一瞬間失效,網絡上很多博客都在強調解決雪崩的策略是隨機過期時間,這個非常不準確,舉個例子,銀行做活動,之前這個利息系數為2%,過了零點系數改為3%,這種情況能將用戶的對應的key改為隨機過期嗎?如果用的過去的數據叫臟數據。
明顯不可以,同樣存錢f0c;你存到年底利息300萬,隔壁才200萬,這不得打架啊,開玩笑~
正確的思路是,首先要看看這個Key過期是不是時點性有關,時點性無關的話,可以隨機過期時間解決。
如果是時點性有關,例如剛剛說的銀行某一天改變某系數,那么就要利用強依賴擊穿方案,策略是先過去的線程更新一下所有key。
在后臺更新熱點key的同時,業務層將進來的請求延時一下,例如短暫的睡幾毫秒或者秒,給后面的更新熱點key分散壓力。
到此,相信大家對“Redis擊穿穿透雪崩產生原因是什么及怎么解決”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。