Redis缓存穿透、击穿、雪崩及主从复制
文章目錄
- Redis緩存穿透
- 概念
- 解決方案1-布隆過濾器
- 解決方案2-緩存空對象
- 緩存擊穿
- 概念
- 解決方案1-熱點數據永不過期
- 解決方案2-加互斥鎖
- 緩存雪崩
- 概念
- 解決方案1-Redis高可用
- 解決方案2-限流降級
- 解決方案3-數據預熱
- Redis主從復制
- 簡介
- 配置環境
- 一主兩從
- 兩種模式
- 哨兵模式
- 概述
- 哨兵的作用
- 故障切換的過程
Redis緩存穿透
查不到
概念
用戶需要查詢數據時,發現Redis中沒有,也就是緩存沒有命中,于是就向持久層數據庫發起查詢,發現也沒有這個數據,于是本次查詢失敗。
當用戶很多的時候,緩存都沒有命中,又會請求數據庫,就會給數據庫帶來很大的壓力,這個就是緩存穿透
解決方案1-布隆過濾器
布隆過濾器是一種算法,是用戶檢測一個元素是否在一個集合中,存在一定的誤差
可以將所有可能查詢的參數以hash形式來進行存儲,在控制層進行校驗,不符合的則丟棄,從而避免對數據庫的查詢壓力
解決方案2-緩存空對象
當存儲層不命中時,及時返回一個空對象也將其緩存起來,同時會設置一個過期時間,之后在訪問這個數據會從緩存中獲取,既能保證數據的有效性也能保護后端數據庫
注意:
即使對緩存設置了過期時間,還是會有緩存和數據庫數據不一致的窗口期,對于需要保持一致性的業務會有影響
緩存擊穿
量太大,緩存過期
概念
緩存擊穿,指一個熱門的key在不停的高并發訪問,當這個key過期的瞬間,持續的高并發的請求就穿破了緩存,直接請求數據庫當key在過期的瞬間,大量的請求并發訪問,會同時訪問數據庫來處查詢最新的數據,回寫到緩存,會導致數據庫瞬間壓力過大
解決方案1-熱點數據永不過期
熱點數據在緩存時不設置過期時間,所以不會出現熱點key過期后造成的數據庫壓力
解決方案2-加互斥鎖
分布式鎖的:使用分布式鎖,保持對每個key同時只有一個線程去查詢后端服務,其他的線程沒有獲取分布式鎖的權限,只能等待。
緩存雪崩
概念
指在某一個時間段,緩存集中過期失效
集中過期,并不是致命問題,比較致命的是,是緩存服務器在某個節點宕機或者斷網,一定的時間段內,數據庫的壓力聚增,對數據庫的壓力是不可預估的,很有可能就把數據庫壓宕機了
解決方案1-Redis高可用
單個Redis可能會掛點,多增設幾臺Redis,這樣一臺掛掉之后其他的也可以繼續服務,就是搭建緩存服務器集群(異地多活)
解決方案2-限流降級
在緩存失效后,通過加鎖或者隊列來控制讀寫數據庫的線程數量,比如對某個key只允許一個線程查詢數據和寫緩存,其他線程等待
解決方案3-數據預熱
在部署之前,先將可能的數據先預先訪問一遍,這樣部分大量訪問的數據就會加載到緩存 中,在即將發生大并發前手動書法加載緩存不同的key,設置不同的過期時間,讓緩存失效的時間盡量均勻
Redis主從復制
簡介
主從復制:指的是一個Redis服務器的數據,復制到其他的Redis服務器,前者稱為主節點(mater/leader)后者稱為從節點(slave/follower),數據的復制是單向,只能從主節點到從節點,master以寫為主,slave節點以讀為主
默認情況,每臺Redis服務器都是主節點,且一個主節點可以有多個從節點(或者沒有從節點),但是一個從節點只能有一個主節點
主從復制作用:
1、數據冗余:主從復制實現的數據的熱備份,是持久化之外的一種數據冗余方式
2、故障恢復:當節點出現問題,可以從其他的節點提供數據服務,實現快速的故障恢復
3、負載均衡:在主從復制的基礎上,配合讀寫分離,可以有主節點來提供寫服務,由從節點提供讀服務,分擔服務器負載,可以提高Redis的并發量
4、高可用:主從復制還是哨兵和集群實現的基礎,主從復制是高可用的基礎
配置環境
配置環境主要配置從庫,不需要配置主庫
復制redis.conf配置文件,修改對應信息 slaveof host ip
1、端口號
2、pid文件名
3、dump.rdb名稱
一主兩從
默認的情況下,每臺Redis服務器都是主節點,主要來配置從節點
兩種模式
一個主機兩個從機
鏈路模式
主機可以寫,從機是可以讀不能寫,主機中的所有的信息和數據,都會保存到從機中
哨兵模式
主從切換技術的方法是:當主服務器宕機后,需要手動把一臺從服務器切換為主服務器,這就需要人工干預,費事費力,還會造成一段時間內服務不可用。這不是一種推薦的方式,更多時候,我們優先考慮哨兵模式。
概述
哨兵模式是一種特殊的模式,首先Redis提供了哨兵的命令,哨兵是一個獨立的進程,作為進程,它會獨立運行。其原理是哨兵通過發送命令,等待Redis服務器響應,從而監控運行的多個Redis實例。
哨兵的作用
1、通過發送命令,讓Redis服務器返回監控其運行狀態,包括主服務器和從服務器。
2、當哨兵監測到master宕機,會自動將slave切換成master,然后通過發布訂閱模式通知其他的從服務器,修改配置文件,讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控,可能會出現哨兵宕機問題,為此,我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控,這樣就形成了多哨兵模式。
故障切換的過程
假設主服務器宕機,哨兵1先檢測到這個結果,系統并不會馬上進行failover過程,僅僅是哨兵1主觀的認為主服務器不可用,這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用,并且數量達到一定值時,那么哨兵之間就會進行一次投票,投票的結果由一個哨兵發起,進行failover操作。切換成功后,就會通過發布訂閱模式,讓各個哨兵把自己監控的從服務器實現切換主機,這個過程稱為客觀下線。這樣對于客戶端而言,一切都是透明的。
總結
以上是生活随笔為你收集整理的Redis缓存穿透、击穿、雪崩及主从复制的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SSM整合使用
- 下一篇: String、StringBuffer、