避免緩存雪崩-九游会j9娱乐平台
❶ redis常見問題
1. 緩存擊穿
緩存擊穿是指一個請求要訪問的數據,緩存中沒有,但資料庫中有的情況。這種情況一般都是緩存過期了。
但是這時由於並發訪問這個緩存的用戶特別多,這是一個熱點 key,這么多用戶的請求同時過來,在緩存裡面沒有取到數據,所以又同時去訪問資料庫取數據,引起資料庫流量激增,壓力瞬間增大,直接崩潰給你看。
所以一個數據有緩存,每次請求都從緩存中快速的返回了數據,但是某個時間點緩存失效了,某個請求在緩存中沒有請求到數據,這時候我們就說這個請求就"擊穿"了緩存。
針對這個場景,對應的解決方案一般來說有三種。
藉助redis setnx命令設置一個標志位就行。設置成功的放行,設置失敗的就輪詢等待。就是在更新緩存時加把鎖
後台開一個定時任務,專門主動更新過期數據
比如程序中設置 why 這個熱點 key 的時候,同時設置了過期時間為 10 分鍾,那後台程序在第 8 分鍾的時候,會去資料庫查詢數據並重新放到緩存中,同時再次設置緩存為 10 分鍾。
其實上面的後台續命思想的最終體現是也是永不過期。
只是後台續命的思想,會主動更新緩存,適用於緩存會變的場景。會出現緩存不一致的情況,取決於你的業務場景能接受多長時間的緩存不一致。
2. 緩存穿透
緩存穿透是指一個請求要訪問的數據,緩存和資料庫中都沒有,而用戶短時間、高密度的發起這樣的請求,每次都打到資料庫服務上,給資料庫造成了壓力。一般來說這樣的請求屬於惡意請求。
解決方案有兩種:
就是在資料庫即使沒有查詢到數據,我們也把這次請求當做 key 緩存起來,value 可以是 null。下次同樣請求就會命中這個 null,緩存層就處理了這個請求,不會對資料庫產生壓力。這樣實現起來簡單,開發成本很低。
3. 緩存雪崩
緩存雪崩是指緩存中大多數的數據在同一時間到達過期時間,而查詢數據量巨大,這時候,又是緩存中沒有,資料庫中有的情況了。
防止雪崩的方案簡單來說就是錯峰過期。
在設置 key 過期時間的時候,在加上一個短的隨機過期時間,這樣就能避免大量緩存在同一時間過期,引起的緩存雪崩。
如果發了雪崩,我們可以有服務降級、熔斷、限流手段來拒絕一些請求,保證服務的正常。但是,這些對用戶體驗是有一定影響的。
4. redis 高可用架構
redis 高可用架構,大家基本上都能想到主從、哨兵、集群這三種模式。
哨兵模式:
它主要執行三種類型的任務:
哨兵其實也是一個分布式系統,我們可以運行多個哨兵。
然後這些哨兵之間需要相互通氣,交流信息,通過投票來決定是否執行自動故障遷移,以及選擇哪個從伺服器作為新的主伺服器。
哨兵之間採用的協議是 gossip,是一種去中心化的協議,達成的是最終一致性。
選舉規則:
❷ 華為技術架構師分享:高並發場景下緩存處理的一些思路
在實際的開發當中,我們經常需要進行磁碟數據的讀取和搜索,因此經常會有出現從資料庫讀取數據的場景出現。但是當數據訪問量次數增大的時候,過多的磁碟讀取可能會最終成為整個系統的性能瓶頸,甚至是壓垮整個資料庫,導致系統卡死等嚴重問題。
常規的應用系統中,我們通常會在需要的時候對資料庫進行查找,因此系統的大致結構如下所示:
1.緩存和資料庫之間數據一致性問題
常用於緩存處理的機制我總結為了以下幾種:
首先來簡單說說cache aside的這種方式:
cache aside模式
這種模式處理緩存通常都是先從資料庫緩存查詢,如果緩存沒有命中則從資料庫中進行查找。
這裡面會發生的三種情況如下:
緩存命中:
當查詢的時候發現緩存存在,那麼直接從緩存中提取。
緩存失效:
當緩存沒有數據的時候,則從database裡面讀取源數據,再加入到cache裡面去。
緩存更新:
當有新的寫操作去修改database裡面的數據時,需要在寫操作完成之後,讓cache裡面對應的數據失效。
關於這種模式下依然會存在缺陷。比如,一個是讀操作,但是沒有命中緩存,然後就到資料庫中取數據,此時來了一個寫操作,寫完資料庫後,讓緩存失效,然後,之前的那個讀操作再把老的數據放進去,所以,會造成臟數據。
facebook的大牛們也曾經就緩存處理這個問題發表過相關的論文,鏈接如下:
分布式環境中要想完全的保證數據一致性是一件極為困難的事情,我們只能夠盡可能的減低這種數據不一致性問題產生的情況。
read through模式
read through模式是指應用程序始終從緩存中請求數據。 如果緩存沒有數據,則它負責使用底層提供程序插件從資料庫中檢索數據。 檢索數據後,緩存會自行更新並將數據返回給調用應用程序。使用read through 有一個好處。
我們總是使用key從緩存中檢索數據, 調用的應用程序不知道資料庫, 由存儲方來負責自己的緩存處理,這使代碼更具可讀性, 代碼更清晰。但是這也有相應的缺陷,開發人員需要給編寫相關的程序插件,增加了開發的難度性。
write through模式
write through模式和read through模式類似,當數據發生更新的時候,先去cache裡面進行更新,如果命中了,則先更新緩存再由cache方來更新database。如果沒有命中的話,就直接更新cache裡面的數據。
2.緩存穿透問題
在高並發的場景中,緩存穿透是一個經常都會遇到的問題。
什麼是緩存穿透?
大量的請求在緩存中沒有查詢到指定的數據,因此需要從資料庫中進行查詢,造成緩存穿透。
會造成什麼後果?
大量的請求短時間內湧入到database中進行查詢會增加database的壓力,最終導致database無法承載客戶單請求的壓力,出現宕機卡死等現象。
常用的解決方案通常有以下幾類:
1.空值緩存
在某些特定的業務場景中,對於數據的查詢可能會是空的,沒有實際的存在,並且這類數據信息在短時間進行多次的反復查詢也不會有變化,那麼整個過程中,多次的請求資料庫操作會顯得有些多餘。
不妨可以將這些空值(沒有查詢結果的數據)對應的key存儲在緩存中,那麼第二次查找的時候就不需要再次請求到database那麼麻煩,只需要通過內存查詢即可。這樣的做法能夠大大減少對於database的訪問壓力。
2.布隆過濾器
通常對於database裡面的數據的key值可以預先存儲在布隆過濾器裡面去,然後先在布隆過濾器裡面進行過濾,如果發現布隆過濾器中沒有的話,就再去redis裡面進行查詢,如果redis中也沒有數據的話,再去database查詢。這樣可以避免不存在的數據信息也去往存儲庫中進行查詢情況。
什麼是緩存雪崩?
當緩存伺服器重啟或者大量緩存集中在某一個時間段失效,這樣在失效的時候,也會給後端系統(比如db)帶來很大壓力。
如何避免緩存雪崩問題?
1.使用加鎖隊列來應付這種問題。當有多個請求湧入的時候,當緩存失效的時候加入一把分布式鎖,只允許搶鎖成功的請求去庫裡面讀取數據然後將其存入緩存中,再釋放鎖,讓後續的讀請求從緩存中取數據。但是這種做法有一定的弊端,過多的讀請求線程堵塞,將機器內存占滿,依然沒有能夠從根本上解決問題。
2.在並發場景發生前,先手動觸發請求,將緩存都存儲起來,以減少後期請求對database的第一次查詢的壓力。數據過期時間設置盡量分散開來,不要讓數據出現同一時間段出現緩存過期的情況。
3.從緩存可用性的角度來思考,避免緩存出現單點故障的問題,可以結合使用 主從 哨兵的模式來搭建緩存架構,但是這種模式搭建的緩存架構有個弊端,就是無法進行緩存分片,存儲緩存的數據量有限制,因此可以升級為redis cluster架構來進行優化處理。(需要結合企業實際的經濟實力,畢竟redis cluster的搭建需要更多的機器)
4.ehcache本地緩存 hystrix限流&降級,避免mysql被打死。
使用 ehcache本地緩存的目的也是考慮在 redis cluster 完全不可用的時候,ehcache本地緩存還能夠支撐一陣。
使用 hystrix進行限流 & 降級 ,比如一秒來了5000個請求,我們可以設置假設只能有一秒 2000個請求能通過這個組件,那麼其他剩餘的 3000 請求就會走限流邏輯。
然後去調用我們自己開發的降級組件(降級),比如設置的一些默認值呀之類的。以此來保護最後的 mysql 不會被大量的請求給打死。
❸ 該怎麼解決 redis 緩存穿透和緩存雪崩問題
緩存雪崩: 由於緩存層承載著大量請求,有效地 保護了存儲層,但是如果緩存層由於某些原因不能提供服務,比如 redis 節點掛掉了,熱點 key 全部失效了,在這些情況下,所有的請求都會直接請求到資料庫,可能會造成資料庫宕機的情況。
預防和解決緩存雪崩問題,可以從以下三個方面進行著手:
1、使用 redis 高可用架構:使用 redis 集群來保證 redis 服務不會掛掉
2、緩存時間不一致: 給緩存的失效時間,加上一個隨機值,避免集體失效
3、限流降級策略:有一定的備案,比如個性推薦服務不可用了,換成熱點數據推薦服務
緩存穿透: 緩存穿透是指查詢一個根本不存在的數據,這樣的數據肯定不在緩存中,這會導致請求全部落到資料庫上,有可能出現資料庫宕機的情況。
預防和解決緩存穿透問題,可以考慮以下兩種方法:
1、緩存空對象: 將空值緩存起來,但是這樣就有一個問題,大量無效的空值將佔用空間,非常浪費。
2、布隆過濾器攔截: 將所有可能的查詢key 先映射到布隆過濾器中,查詢時先判斷key是否存在布隆過濾器中,存在才繼續向下執行,如果不存在,則直接返回。布隆過濾器有一定的誤判,所以需要你的業務允許一定的容錯性。