過期策略

定期刪除

redis 會將每個設置了過期時間的 key 放入到一個獨立的字典中，以后會定期遍歷這個字典來刪除到期的 key。

定期刪除策略

Redis 默認會每秒進行十次過期掃描（100ms一次），過期掃描不會遍歷過期字典中所有的 key，而是采用了一種簡單的貪心策略。

從過期字典中隨機 20 個 key；

刪除這 20 個 key 中已經過期的 key；

如果過期的 key 比率超過 1/4，那就重復步驟 1；

惰性刪除

除了定期遍歷之外，它還會使用惰性策略來刪除過期的 key，所謂惰性策略就是在客戶端訪問這個 key 的時候，redis 對 key 的過期時間進行檢查，如果過期了就立即刪除，不會給你返回任何東西。

定期刪除是集中處理，惰性刪除是零散處理。

為什么要采用定期刪除+惰性刪除2種策略呢？

如果過期就刪除。假設redis里放了10萬個key，都設置了過期時間，你每隔幾百毫秒，就檢查10萬個key，那redis基本上就死了，cpu負載會很高的，消耗在你的檢查過期key上了

但是問題是，定期刪除可能會導致很多過期key到了時間并沒有被刪除掉，那咋整呢？所以就是惰性刪除了。這就是說，在你獲取某個key的時候，redis會檢查一下 ，這個key如果設置了過期時間那么是否過期了？如果過期了此時就會刪除，不會給你返回任何東西。

并不是key到時間就被刪除掉，而是你查詢這個key的時候，redis再懶惰的檢查一下

通過上述兩種手段結合起來，保證過期的key一定會被干掉。

所以說用了上述2種策略后，下面這種現象就不難解釋了：數據明明都過期了，但是還占有著內存

內存淘汰策略

這個問題可能有小伙伴們遇到過，放到Redis中的數據怎么沒了？

因為Redis將數據放到內存中，內存是有限的，比如redis就只能用10個G，你要是往里面寫了20個G的數據，會咋辦？當然會干掉10個G的數據，然后就保留10個G的數據了。那干掉哪些數據？保留哪些數據？當然是干掉不常用的數據，保留常用的數據了

Redis提供的內存淘汰策略有如下幾種：

1.noeviction 不會繼續服務寫請求 (DEL 請求可以繼續服務)，讀請求可以繼續進行。這樣可以保證不會丟失數據，但是會讓線上的業務不能持續進行。這是默認的淘汰策略。

2.volatile-lru 嘗試淘汰設置了過期時間的 key，最少使用的 key 優先被淘汰。沒有設置過期時間的 key 不會被淘汰，這樣可以保證需要持久化的數據不會突然丟失。（這個是使用最多的）

3.volatile-ttl 跟上面一樣，除了淘汰的策略不是 LRU，而是 key 的剩余壽命 ttl 的值，ttl 越小越優先被淘汰。

4.volatile-random 跟上面一樣，不過淘汰的 key 是過期 key 集合中隨機的 key。

5.allkeys-lru 區別于 volatile-lru，這個策略要淘汰的 key 對象是全體的 key 集合，而不只是過期的 key 集合。這意味著沒有設置過期時間的 key 也會被淘汰。

6.allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。

持久化策略

Redis的數據是存在內存中的，如果Redis發生宕機，那么數據會全部丟失，因此必須提供持久化機制。

Redis 的持久化機制有兩種，第一種是快照（RDB），第二種是 AOF 日志。快照是一次全量備份，AOF 日志是連續的增量備份。快照是內存數據的二進制序列化形式，在存儲上非常緊湊，而 AOF 日志記錄的是內存數據修改的指令記錄文本。AOF 日志在長期的運行過程中會變的無比龐大，數據庫重啟時需要加載 AOF 日志進行指令重放，這個時間就會無比漫長。所以需要定期進行 AOF 重寫，給 AOF 日志進行瘦身。

RDB是通過Redis主進程fork子進程，讓子進程執行磁盤 IO 操作來進行 RDB 持久化，AOF 日志存儲的是 Redis 服務器的順序指令序列，AOF 日志只記錄對內存進行修改的指令記錄。即RDB記錄的是數據，AOF記錄的是指令

RDB和AOF到底該如何選擇？

1.不要僅僅使用 RDB，因為那樣會導致你丟失很多數據，因為RDB是隔一段時間來備份數據

2.也不要僅僅使用 AOF，因為那樣有兩個問題，第一，通過 AOF 做冷備沒有RDB恢復速度快; 第二，RDB 每次簡單粗暴生成數據快照，更加健壯，可以避免 AOF 這種復雜的備份和恢復機制的 bug

3.用RDB恢復內存狀態會丟失很多數據，重放AOP日志又很慢。Redis4.0推出了混合持久化來解決這個問題。將 rdb 文件的內容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結束的這段時間發生的增量 AOF 日志，通常這部分 AOF 日志很小。于是在 Redis 重啟的時候，可以先加載 rdb 的內容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。

緩存雪崩和緩存穿透

緩存雪崩是什么？

假設有如下一個系統，高峰期請求為5000次/秒，4000次走了緩存，只有1000次落到了數據庫上，數據庫每秒1000的并發是一個正常的指標，完全可以正常工作，但如果緩存宕機了，每秒5000次的請求會全部落到數據庫上，數據庫立馬就死掉了，因為數據庫一秒最多抗2000個請求，如果DBA重啟數據庫，立馬又會被新的請求打死了，這就是緩存雪崩。

如何解決緩存雪崩

事前：redis高可用，主從+哨兵，redis cluster，避免全盤崩潰

事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL被打死

事后：redis持久化，快速恢復緩存數據

緩存穿透是什么？

假如客戶端每秒發送5000個請求，其中4000個為黑客的惡意攻擊，即在數據庫中也查不到。舉個例子，用戶id為正數，黑客構造的用戶id為負數，

如果黑客每秒一直發送這4000個請求，緩存就不起作用，數據庫也很快被打死。

如何解決緩存穿透

查詢不到的數據也放到緩存，value為空，如set -999 “”

總而言之，緩存雪崩就是緩存失效，請求全部全部打到數據庫，數據庫瞬間被打死。緩存穿透就是查詢了一個一定不存在的數據，并且從存儲層查不到的數據沒有寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義

總結

以上是生活随笔為你收集整理的Reds 过期策略 内存淘汰策略 持久化策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。