① 該怎麼解決 Redis 緩存穿透和緩存雪崩問題
緩存雪崩： 由於緩存層承載著大量請求，有效地 保護了存儲層，但是如果緩存層由於某些原因不能提供服務，比如 Redis 節點掛掉了，熱點 key 全部失效了，在這些情況下，所有的請求都會直接請求到資料庫，可能會造成資料庫宕機的情況。
預防和解決緩存雪崩問題，可以從以下三個方面進行著手：
1、使用 Redis 高可用架構：使用 Redis 集群來保證 Redis 服務不會掛掉
2、緩存時間不一致： 給緩存的失效時間，加上一個隨機值，避免集體失效
3、限流降級策略：有一定的備案，比如個性推薦服務不可用了，換成熱點數據推薦服務
緩存穿透： 緩存穿透是指查詢一個根本不存在的數據，這樣的數據肯定不在緩存中，這會導致請求全部落到資料庫上，有可能出現資料庫宕機的情況。
預防和解決緩存穿透問題，可以考慮以下兩種方法：
1、緩存空對象： 將空值緩存起來，但是這樣就有一個問題，大量無效的空值將佔用空間，非常浪費。
2、布隆過濾器攔截： 將所有可能的查詢key 先映射到布隆過濾器中，查詢時先判斷key是否存在布隆過濾器中，存在才繼續向下執行，如果不存在，則直接返回。布隆過濾器有一定的誤判，所以需要你的業務允許一定的容錯性。
② redis如何實現自定義過期時間
找到你們項目中的redis工具類，裡面加一個方法
我使用的是RedisTemplate
public boolean expire(final String key, long expire) {
return redisTemplate.expire(key, expire, TimeUnit.SECONDS);
}
用來設置對應的key的生命周期。
記得採納哦
③ java怎麼模擬redis緩存超時
從expires中查找key的過期時間，如果不存在說明對應key沒有設置過期時間，直接返回。
如果是slave機器，則直接返回，因為Redis為了保證數據一致性且實現簡單，將緩存失效的主動權交給Master機器，slave機器沒有許可權將key失效。
如果當前是Master機器，且key過期，則master會做兩件重要的事情：1）將刪除命令寫入AOF文件。2）通知Slave當前key失效，可以刪除了。
master從本地的字典中將key對於的值刪除。
主動失效機制
主動失效機制也叫積極失效機制，即服務端定時的去檢查失效的緩存，如果失效則進行相應的操作。
我們都知道Redis是單線程的，基於事件驅動的，Redis中有個EventLoop，EventLoop負責對兩類事件進行處理：
一類是IO事件，這類事件是從底層的多路復用器分離出來的。
一類是定時事件，這類事件主要用來事件對某個任務的定時執行。
④ Redis緩存雪崩就這么簡單
在實際項目開發中，我們都知道Redis不可能把所有的數據都緩存起來( 內存昂貴且有限 )，所以Redis需要對數據設置過期時間，並採用的是惰性刪除+定期刪除兩種策略對過期鍵刪除。
如果緩存數據 設置的過期時間是相同 的，並且Redis恰好將這部分數據全部刪光了。這就會導致在這段時間內，這些緩存 同時失效 ，全部請求到資料庫中。
這就是緩存雪崩 ：
緩存雪崩如果發生了，很可能就把我們的資料庫 搞垮 ，導致整個服務癱瘓，造成的後果很嚴重。
對緩存數據設置相同的過期時間，導致某段時間內緩存失效。」
對於「Redis掛掉了」，我們可以有以下的思路：
⑤ redis常見問題
1. 緩存擊穿
緩存擊穿是指一個請求要訪問的數據，緩存中沒有，但資料庫中有的情況。這種情況一般都是緩存過期了。
但是這時由於並發訪問這個緩存的用戶特別多，這是一個熱點 key，這么多用戶的請求同時過來，在緩存裡面沒有取到數據，所以又同時去訪問資料庫取數據，引起資料庫流量激增，壓力瞬間增大，直接崩潰給你看。
所以一個數據有緩存，每次請求都從緩存中快速的返回了數據，但是某個時間點緩存失效了，某個請求在緩存中沒有請求到數據，這時候我們就說這個請求就"擊穿"了緩存。
針對這個場景，對應的解決方案一般來說有三種。
藉助Redis setNX命令設置一個標志位就行。設置成功的放行，設置失敗的就輪詢等待。就是在更新緩存時加把鎖
後台開一個定時任務，專門主動更新過期數據
比如程序中設置 why 這個熱點 key 的時候，同時設置了過期時間為 10 分鍾，那後台程序在第 8 分鍾的時候，會去資料庫查詢數據並重新放到緩存中，同時再次設置緩存為 10 分鍾。
其實上面的後台續命思想的最終體現是也是永不過期。
只是後台續命的思想，會主動更新緩存，適用於緩存會變的場景。會出現緩存不一致的情況，取決於你的業務場景能接受多長時間的緩存不一致。
2. 緩存穿透
緩存穿透是指一個請求要訪問的數據，緩存和資料庫中都沒有，而用戶短時間、高密度的發起這樣的請求，每次都打到資料庫服務上，給資料庫造成了壓力。一般來說這樣的請求屬於惡意請求。
解決方案有兩種：
就是在資料庫即使沒有查詢到數據，我們也把這次請求當做 key 緩存起來，value 可以是 NULL。下次同樣請求就會命中這個 NULL，緩存層就處理了這個請求，不會對資料庫產生壓力。這樣實現起來簡單，開發成本很低。
3. 緩存雪崩
緩存雪崩是指緩存中大多數的數據在同一時間到達過期時間，而查詢數據量巨大，這時候，又是緩存中沒有，資料庫中有的情況了。
防止雪崩的方案簡單來說就是錯峰過期。
在設置 key 過期時間的時候，在加上一個短的隨機過期時間，這樣就能避免大量緩存在同一時間過期，引起的緩存雪崩。
如果發了雪崩，我們可以有服務降級、熔斷、限流手段來拒絕一些請求，保證服務的正常。但是，這些對用戶體驗是有一定影響的。
4. Redis 高可用架構
Redis 高可用架構，大家基本上都能想到主從、哨兵、集群這三種模式。
哨兵模式：
它主要執行三種類型的任務：
哨兵其實也是一個分布式系統，我們可以運行多個哨兵。
然後這些哨兵之間需要相互通氣，交流信息，通過投票來決定是否執行自動故障遷移，以及選擇哪個從伺服器作為新的主伺服器。
哨兵之間採用的協議是 gossip，是一種去中心化的協議，達成的是最終一致性。
選舉規則：
⑥ 基於數據結構和演算法的深入應用--2.失效演算法與應用
失效演算法常見於緩存系統中.因為緩存往往占據大量內存,而內存空間是相對昂貴且空間有限,那麼針對一部分值,就要依據相應的演算法進行失效或者移除操作.
first in first out,先來先淘汰.這種演算法在培輪每一次新數據插入時,如果隊列已滿,就將最早插入的數據移除.
可以方便的藉助linkedlist來實現
Least Recently Used,最近最少使用,淘汰最後一次使用時間最久遠的數據.FIFO非常罩野粗暴,不管有沒有用到,直接配悶信踢掉時間久的元素,而LRU認為,最近頻繁使用過的數據,將來很大程度上也會被頻繁使用,故而淘汰那些懶惰的數據.LinkedHashMap 數組 鏈表均可實現LRU, 下面仍然以鏈表為例: 新加入的數據放在頭部,最近訪問的也移動到頭部,空間滿時,將尾部元素刪除
Least Frequently Used, 它要淘汰的是最近一段時間內,使用次數最少的值.可以認為比LRU多了一重判斷.LFU需要時間和次數兩個維度的參考指標.需要注意的是,兩個維度就可能涉及到同一個時間段內,訪問次數相同的情況,就必須內置一個計數器和一個隊列,計數器算數,隊列放置相同計數時的訪問時間
redis屬於緩存失效的典型應用場景,常用策略是......
⑦ mysql模擬redis過期失效
您想問的是mysql模擬redis過期失效怎麼出里？定時過期。
每個設置輪斗過期時間的key都需要創建一個定胡桐和時器，到過期時間就會立即清除。該策略可以立即清除過期的數據，對內存很友褲盯好；但是會佔用大量的CPU資源去處理過期的數據，從而影響緩存的響應時間和吞吐量。
⑧ Redis緩存過期機制
一、針對與設置了過期時間的key值
1.（主動）定期刪除：定時隨機的檢查過期的key，如果過期則清理刪除
redis.conf(每秒檢查的次數1-500)配置: hz 10
2.（被動）惰性刪除：當客戶端請求到一個已經過期的key時，redis會檢查是否過期並刪除
所以，雖然key過期了，但是沒被清理的話，還是會占內存的。
二、內存淘汰管理機制Memory Management
當內存占滿之後，redis提供緩存淘汰機制。
redis.conf: maxmemory <bytes>
* noeviction：舊緩存永不過期，新緩存設置不了，返回錯誤
* allkeys-lru：清除最少用的舊緩存，然後保存新的緩存（推薦使用）
* allkeys-random：在所有的緩存中隨機刪除（不推薦）
* volatile-lru：在那些設置了expire過期時間的緩存中，清除最少用的舊緩存，然後保存新的緩存
* volatile-random：在那些設置了expire過期時間的緩存中，隨機刪除緩存
* volatile-ttl：在那些設置了expire過期時間的緩存中，刪除即將過期的
⑨ SpringBoot整合SpringSeesion實現Redis緩存
使用Spring Boot開發項目時我們經常需要存儲Session，因為Session中會存一些用戶信息或者登錄信息。傳統的web服務是將session存儲在內存中的，一旦服務掛了，session也就消失了，這時候我們就需要將session存儲起來，而Redis就是用來緩存seesion的一種非關系型資料庫，我們可以通過配置或者註解的方式將Spring Boot和Redis整合。而在分布式系統中又會涉及到session共享的問題，多個服務同時部署時session需要共享，Spring Session可以幫助我們實現這一功能。將Spring Session集成到Spring Boot框架中並使用Redis進行緩存是目前非常流行的解決方案，接下來就跟著我一起學習吧。
工具/材料
IntelliJ IDEA
首先我們創建一個Spring Boot 2.x的項目，在application.properties配置文件中添加Redis的配置，Spring和Redis的整合可以參考我其他的文章，此處不再詳解。我們設置服務埠server.port為8080埠用於啟動第一個服務。
接下來我們需要在pom文件中添加spring-boot-starter-data-redis和spring-session-data-redis這兩個依賴，spring-boot-starter-data-redis用於整合Spring Boot和Redis，spring-session-data-redis集成了spring-session和spring-data-redis，提供了session與redis的整合方案。
接下來我們創建一個配置類RedisSessionConfig，這個類使用@Configuration註解表明這是一個配置類。在這個類上我們同時添加註解@EnableRedisHttpSession，表示開啟Redis的Session管理。如果需要設置失效時間可以使用@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 3600)表示一小時後失效。若同時需要設置Redis的命名空間則使用@EnableRedisHttpSession(maxInactiveIntervalInSeconds=3600, redisNamespace="{spring.session.redis.namespace}") ，其中{spring.session.redis.namespace}表示從配置文件中讀取這個命名空間。
配置完成後我們寫一個測試類SessionController，在這個類中我們寫兩個方法，一個方法用於往session中存數據，一個用於從session中取數據，代碼如下圖所示，我們存取請求的url。啟動類非常簡單，一般都是通用的，我們創建一個名為SpringbootApplication的啟動類，使用main方法啟動。
接下來我們使用Postman分別請求上面兩個介面，先請求存數據介面，再請求取數據介面，結果如下圖所示，我們可以看到數據已從redis中取出。另外需要注意sessionId的值，這是session共享的關鍵。
為了驗證兩個服務是否共享了session，我們修改項目的配置文件，將服務埠server.port改為8090，然後再啟動服務。此時我們不必在請求存數據的介面，只需要修改請求埠號再一次請求取數據的介面即可。由下圖可以看到兩次請求的sessionId值相同，實現了session的共享。
以上我們完成了SpringBoot整合SpringSeesion實現Redis緩存的功能，在此我們還要推薦一個Redis的可視化工具RedisDesktopManager，我們可以配置Redis資料庫的連接，然後便可以非常直觀地查看到存儲到Redis中的session了，如下圖所示，session的命名空間是share，正是從配置文件中讀取到的。
特別提示
如果Redis伺服器是很多項目共用的，非常建議配置命名空間，否則同時打開多個項目的瀏覽器頁面可能會導致session錯亂的現象。
⑩ 2022-03-12 SpringBoot 使用redis做緩存，設置失效時間以及序列化
SpringBoot的cache緩存，是針對返回值的一種操作
springboot使用redis做緩存時，默認只需要導入redis依賴，即可實現使用redis做緩存
不需要導入cache依賴
在啟動類上加上 @EnableCaching 即可開啟緩存功能
關於各個註解的使用，這里不再細說，網上詳細的教程很多，這里主要講一下如何指定過期時間
默認是永不過期，如果需要指定過期時間，則需要增加配置類