redis快取擊穿

2021-09-27 06:35:00 字數 653 閱讀 7702

1、快取擊穿出現的場景

我們知道redis的資料是儲存在記憶體的,而記憶體是有限的,所以一般會設定過期時間,當某個key過期了,而此時大量的併發來請求這個key,導致都去請求mysql啦,而mysql的併發連線數很低,缺少了redis這層盾牌,mysql自然扛不住,這不是架構的問題,因為之前的架構中有redis的,系統是扛得住的,雪崩是一種特殊情況。

2、快取擊穿的預防

**加鎖!!

傳統獲取快取的寫法:

if ($data = $cache->get($cachekey)) else
key已過期,現在有1w的併發同時到達,所以都去到mysql了。我們需要優化一下,使只有1個去到mysql,剩下的9999去到redis。

使用zookeeper分布式鎖來控制。參考:

if ($data = $cache->get($cachekey)) else
看起來獲取鎖的地方阻塞太嚴重了,可以優化為如果獲取鎖失敗就讀一次快取,但是這樣不利於封裝,其實,大量併發走到else的情況也就在快取失效的那一刻,在這一刻的效能會有所下降而已。

快取雪崩:

大量的key集中過期,導致資料庫壓力瞬間增大。防止大量key在同一時間過期,將過期時間分散,每個key的過期時間上加乙個隨機數。

Redis快取擊穿

什麼是快取擊穿 key對應的資料存在,但是在redis中key過期了,此時如有大量的併發請求過來,這些請求發現快取過期一般都會從後端伺服器載入資料並回設到快取,這個時候大併發請求可能會瞬間把後端db壓垮 如圖 出現快取穿透的特點 1.資料庫訪問壓力瞬間增加 2.redis裡面出現大量key過期 3....

redis 快取擊穿 3

在談論快取擊穿之前,我們先來回憶下從快取中載入資料的邏輯,如下圖所示 因此,如果黑客每次故意查詢乙個在快取內必然不存在的資料,導致每次請求都要去儲存層去查詢,這樣快取就失去了意義。如果在大流量下資料庫可能掛掉。這就是快取擊穿。場景如下圖所示 我們正常人在登入首頁的時候,都是根據userid來命中資料...

redis快取擊穿問題

1.讀模式,如何讀取乙個資料,應該遵循先從快取中讀取,如果快取中沒有,再在資料庫讀取,如果在資料庫查到資料則再放到快取中,並返回 2.寫模式,如何保證快取中的資料和資料庫中的資料是一致的 可以使用雙寫模式或失效模式 指查詢乙個一定不存在的資料,由於快取是不命中的,將會查詢資料庫,但是資料庫也無此記錄...