什麼場景會導致緩存雪崩

Ⅰ 該怎麼解決 Redis 緩存穿透和緩存雪崩問題

緩存雪崩： 由於緩存層承載著大量請求，有效地 保護了存儲層，但是如果緩存層由於某些原因不能提供服務，比如 Redis 節點掛掉了，熱點 key 全部失效了，在這些情況下，所有的請求都會直接請求到資料庫，可能會造成資料庫宕機的情況。
預防和解決緩存雪崩問題，可以從以下三個方面進行著手：
1、使用 Redis 高可用架構：使用 Redis 集群來保證 Redis 服務不會掛掉
2、緩存時間不一致： 給緩存的失效時間，加上一個隨機值，避免集體失效
3、限流降級策略：有一定的備案，比如個性推薦服務不可用了，換成熱點數據推薦服務
緩存穿透： 緩存穿透是指查詢一個根本不存在的數據，這樣的數據肯定不在緩存中，這會導致請求全部落到資料庫上，有可能出現資料庫宕機的情況。
預防和解決緩存穿透問題，可以考慮以下兩種方法：
1、緩存空對象： 將空值緩存起來，但是這樣就有一個問題，大量無效的空值將佔用空間，非常浪費。
2、布隆過濾器攔截： 將所有可能的查詢key 先映射到布隆過濾器中，查詢時先判斷key是否存在布隆過濾器中，存在才繼續向下執行，如果不存在，則直接返回。布隆過濾器有一定的誤判，所以需要你的業務允許一定的容錯性。

Ⅱ redis常見問題

1. 緩存擊穿

緩存擊穿是指一個請求要訪問的數據，緩存中沒有，但資料庫中有的情況。這種情況一般都是緩存過期了。

但是這時由於並發訪問這個緩存的用戶特別多，這是一個熱點 key，這么多用戶的請求同時過來，在緩存裡面沒有取到數據，所以又同時去訪問資料庫取數據，引起資料庫流量激增，壓力瞬間增大，直接崩潰給你看。

所以一個數據有緩存，每次請求都從緩存中快速的返回了數據，但是某個時間點緩存失效了，某個請求在緩存中沒有請求到數據，這時候我們就說這個請求就"擊穿"了緩存。

針對這個場景，對應的解決方案一般來說有三種。

藉助Redis setNX命令設置一個標志位就行。設置成功的放行，設置失敗的就輪詢等待。就是在更新緩存時加把鎖

後台開一個定時任務，專門主動更新過期數據

比如程序中設置 why 這個熱點 key 的時候，同時設置了過期時間為 10 分鍾，那後台程序在第 8 分鍾的時候，會去資料庫查詢數據並重新放到緩存中，同時再次設置緩存為 10 分鍾。

其實上面的後台續命思想的最終體現是也是永不過期。

只是後台續命的思想，會主動更新緩存，適用於緩存會變的場景。會出現緩存不一致的情況，取決於你的業務場景能接受多長時間的緩存不一致。

2. 緩存穿透

緩存穿透是指一個請求要訪問的數據，緩存和資料庫中都沒有，而用戶短時間、高密度的發起這樣的請求，每次都打到資料庫服務上，給資料庫造成了壓力。一般來說這樣的請求屬於惡意請求。

解決方案有兩種：

就是在資料庫即使沒有查詢到數據，我們也把這次請求當做 key 緩存起來，value 可以是 NULL。下次同樣請求就會命中這個 NULL，緩存層就處理了這個請求，不會對資料庫產生壓力。這樣實現起來簡單，開發成本很低。

3. 緩存雪崩

緩存雪崩是指緩存中大多數的數據在同一時間到達過期時間，而查詢數據量巨大，這時候，又是緩存中沒有，資料庫中有的情況了。

防止雪崩的方案簡單來說就是錯峰過期。

在設置 key 過期時間的時候，在加上一個短的隨機過期時間，這樣就能避免大量緩存在同一時間過期，引起的緩存雪崩。

如果發了雪崩，我們可以有服務降級、熔斷、限流手段來拒絕一些請求，保證服務的正常。但是，這些對用戶體驗是有一定影響的。

4. Redis 高可用架構

Redis 高可用架構，大家基本上都能想到主從、哨兵、集群這三種模式。

哨兵模式：

它主要執行三種類型的任務：

哨兵其實也是一個分布式系統，我們可以運行多個哨兵。

然後這些哨兵之間需要相互通氣，交流信息，通過投票來決定是否執行自動故障遷移，以及選擇哪個從伺服器作為新的主伺服器。

哨兵之間採用的協議是 gossip，是一種去中心化的協議，達成的是最終一致性。

選舉規則：

Ⅲ 用雲資料庫會被打死嗎

緩存雪崩、擊穿、穿透及解決方案
1、緩存雪崩，出現過程，假如一個系統，高峰期5000次/s，4000次走了緩存，1000次走資料庫，資料庫1000/s是正常指標，完全可以工作，但是如果緩存宕機了，或者緩存設置了相同的過期時間，導致緩存同一時間失效，然後5000次請求都打在了資料庫上，資料庫立馬被打死了，資料庫一般1s最多抗2000個請求(這個取決於具體硬體配置)，如果DBA重啟資料庫，同樣的立馬會繼續被打死，這就是緩存雪崩。

Ⅳ redis緩存使用中的熱key問題

在Redis中，訪問頻率高的key稱為熱點key，當某一熱點key的請求到Server主機時，由於請求量特別大，導致主機資源不足，甚至宕機，影響正常的服務

1.用戶消費的數據遠大於生產的數據，比如熱賣商品、熱點新聞、熱點評論等，這些典型的讀多寫少的場景會產生熱點問題

2.請求分片集中，超過單Server的性能極限，比如 固定名稱key，哈希落入一台Server，訪問量極大的情況，超過Server極限時，就會導致熱點Key問題的產生

1.流量集中，達到物理網卡上限，影響其他key的訪問。

2.請求過多，緩存分片服務被打垮，不能通過擴容解決,且不能發揮集群多分片的優勢。

3.緩存擊穿，可能打到DB,引起業務雪崩。

1.憑借業務經驗，進行預估哪些是熱key

2.客戶端統計收集，本地統計或者上報

3.如果服務端有代理層，可以在代理層進行收集上報

1.增加分片副本，分擔讀流量

2.熱key備份，比如key，備份為key1,key2……keyN，同樣的數據N個備份，N個備份分布到不同分片，訪問時可隨機訪問N個備份中的一個,進一步分擔讀流量

3.使用本地緩存，發現熱key後，將熱key對應數據載入到應用伺服器本地緩存中，訪問熱key數據時，直接從本地緩存中獲取，而不會請求到redis伺服器。

http://tigcms.jd.com/details/S11dBQ5M7.html
https://help.aliyun.com/document_detail/67252.html
https://www.cnblogs.com/rjzheng/p/10874537.html

Ⅳ 緩存擊穿、穿透、雪崩及Redis分布式鎖

分布式鎖: setnx ,redisson 並發問題
冪等問題: 落表狀態,Redis

緩存擊穿: 指緩存中無,db中有
原因: 一個key高並發恰好失效導致大量請求到db
方案: 加鎖,自旋鎖,或一個線程查db,一個線程監控(直接用Redisson分布式鎖)

緩存穿透:指緩存和db中均無
原因: 一般是惡意請求
方案: 加布隆過濾,或查db無時,也設置緩存,value為某些特殊表示或"null"

雪崩:指緩存同時大量失效
原因: 大量的key同時失效,db壓力加大
方案: 設置失效時間是增加隨機數

問題方案文獻:
https://www.jianshu.com/p/31ab9b020cd9 (圖例分析)

https://blog.csdn.net/fcvtb/article/details/89478554

Redis分布式鎖:

事務未執行完鎖已到期釋放問題：使用Redissoin解決續租問題，內部已解決

分布式鎖文獻:
https://www.jianshu.com/p/4838f8be00c9
https://blog.csdn.net/qq_30038111/article/details/90696233 (setnx + expire同時操作)

====================================

https://www.runoob.com/redis/keys-scan.html
https://www.jianshu.com/p/611a492d9121 Redis原理與應用