各位老鐵們，大家好，今天由我來為大家分享redis雪崩和穿透，以及redis雪崩怎么解決的相關問題知識，希望對大家有所幫助。如果可以幫助到大家，還望關注收藏下本站，您的支持是我們最大的動力，謝謝大家了哈，下面我們開始吧！

海量數據下如何正確訪問Redis服務才不會掛掉

要保證Redis不會掛掉，也就是提高Redis的高可用性，可以從這么幾個方面考慮。

集群式部署方式

Redis單副本：也就是只部署一臺Redis，不需要節點之間的數據同步，架構簡單，部署方便；但是單臺機器畢竟是有風險的，按照題目中【海量數據】的場景，是不能達到高可用要求的。

Redis主從：主從實例可以部署在不同的物理服務器上，充分利用多臺服務器的資源，在主庫發生故障的時候，可以進行主備切換，從而保證系統的穩定運行，甚至可以做到讀寫分離，主庫專門用作寫操作，一臺或多臺備庫進行讀操作；但是當主庫發生故障的時候（如果沒有HA方案的話），是需要手動進行主備切換的。

RedisSentinel：部署架構分為兩部分【Sentinel集群】和【數據集群】；Sentinel集群是由多個Sentinel節點組成的分布式集群，通常是2N+1臺服務器，可以實現故障發現和轉移、客戶端通知等功能；數據集群用于存儲數據；它能夠解決主從模式下的自動切換問題，并且數據集群是可以橫向擴展的；當然這個架構實現和部署起來，也更為復雜一些；并且這個架構不能做到讀寫分離。

RedisCluster：Redis3.0集群，是分布式集群解決方案之一，物理架構中配置2N個節點（主從一一對應），主節點提供讀寫操作，從節點作為備份；數據分布保存在多個節點上，是一種無中心的架構，如果有部分節點發生故障，能夠實現故障自動轉移和切換，用投票機制完成備庫升級為主庫（下文的Redis分片章節，還會介紹到RedisCluster）。

Redis分片

Redis在3.0之前只支持單實例，在此之前，在數據量比較大的情況，通常有幾種方案可以做到把數據分片保存到多臺服務器上。

客戶端分片：分片邏輯被放到了客戶端上，由客戶端根據路由規則，把數據保存不同的Redis實例中，讀取的時候也是根據規則，去對應的實例上讀取數據；但是當Redis實例數量發生變化的時候（增加實例或減少實例），需要手動地調整分片的規則程序；并且這種部署方式，也增加了運維的成本。

Redis代理組件：在這種架構中，客戶端不再直接訪問Redis實例，而是訪問代理組件，由它管理路由的規則；客戶端不需要關心有幾個Redis實例，數據被路由到哪個實例上；但是由于在客戶端和Redis之間增加了一層代理，多多少少也會產生一些性能上的損耗。

RedisCluster：上文中提到的Redis3.0集群，這里對數據的存儲和路由方式，再介紹幾句：Redis把所有的Key分成了16384個slot，每個Redis實例負責其中一部分slot；每個Redis都知道每個slot在哪個節點上存儲（實例節點定期做數據交換）；當客戶端訪問到一個Redis實例的時候，如果數據不在這個實例上，那么會通過重定向命令引導客戶端訪問數據所在的實例。

熱點數據挑戰單節點的極限

雖然我們已經把數據分散保存到多臺Redis實例上了，但是如果有一個熱點數據被頻繁訪問，超過了單實例的服務器極限，那么該如何解決呢？通常的手段就是做讀寫分離，部署多臺只讀節點，對外提供服務。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

如何解決Redis緩存雪崩、緩存穿透、緩存并發等問題

緩存穿透

很多項目在使用Redis或其他緩存框架的時候，都是先查詢緩存，查詢不的話再查詢數據庫，查到之后再放到內存中；如果一個key值本身就不存在，那么每一次都會查詢數據庫，也就是常說的【緩存穿透】。

應對方法：

如果在Redis中查詢不到，并且查詢數據庫也沒有結果，那么就將這個key寫入到Redis中，value=空，并設置一個超時過期時間，例如五分鐘，那么五分鐘以內的對這個可以的所有查詢就可以攔截下來，如果數據庫有key對應的數據了，那么五分鐘后Redis中的緩存過期，會訪問數據庫并加載緩存；但是如果被惡意攻擊，每次請求的key都不相同且不存在，那么依然會穿透到數據庫；

布隆過濾器：將可能存在的數據Hash到一個足夠大的bitmap上，它可以告訴你“某個key一定不存在或者可能存在”，一個一定不存在的數據會被bitmap攔截。

緩存雪崩

很多時候，Redis中的緩存是要設置過期時間的，假如Redis中的數據，過期時間都設置成一樣的，那么到了時間之后，全部緩存過期失效，下一秒所有的請求都會訪問數據庫，那么數據庫可能因為訪問量多大導致“崩潰”，這就是緩存雪崩。

應對方法：

最暴力的解決辦法，緩存不設置自動過期時間，只要緩存不崩，數據庫就不會崩。

另外一個辦法，就是讓緩存過期時間不那么一致，比如一批緩存數據24小時后過期，那么就在這個基礎上，每條緩存的過期時間前后隨機1-6000秒（1-10分鐘）。

緩存并發

大多數時候，我們的程序訪問Redis都不可能是單線程，那么當多個Client并發對Redis進行setkey操作的時候，可能會產生一些問題；其實Redis本身是單線程的，這種時候會按照先后順序進行操作；或者把操作放在隊列中，按順序執行；

但比如這種情況：

token過期，有兩個線程都去重新獲取token；

線程1獲取token1；

線程2獲取到token2，此時token1過期；

線程1把token1放到Redis，再拿著token1去調用服務，發現過期了，繼續去請求token3，此時token2過期；

線程2把token2放到Redis，再拿著token2去調用服務，發現過期了，繼續去請求token4，此時token3過期；

......

這就需要我們在更新緩存的時候，做一些控制了。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

好了，文章到這里就結束啦，如果本次分享的redis雪崩和穿透和redis雪崩怎么解決問題對您有所幫助，還望關注下本站哦！