一、過期策略

1.1、定時刪除

1.1.1、過期

• Redis 所有的數(shù)據(jù)結(jié)構(gòu)都可以設(shè)置過期時間，時間一到，就會自動刪除。
• 但是會不會因為同一時間太多的key 過期，以至于忙不過來。
• 同時因為Redis 是單線程的，刪除的時間也會占用線程的處理時間，如果刪除的大過于繁忙，會不會導(dǎo)致線上讀寫指令出現(xiàn)卡頓。

1.1.2、過期的 key 集合

• redis 會將每個設(shè)置了過期時間的key 放入到一個獨立的字典中，以后會定時遍歷這個字典來刪除到期的 key。
• 除了定時遍歷之外，它還會使用惰性策略來刪除過期的 key，所謂惰性策略就是在客戶端訪問這個 key 的時候，redis 對 key 的過期時間進行檢查，如果過期了就立即刪除。
• 定時刪除是集中處理，惰性刪除是零散處理。

1.1.3、定時掃描策略

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

（1）、從過期字典中隨機 20 個 key;

（2）、刪除這 20 個 key 中已經(jīng)過期的 key;

（3）、 如果過期的 key 比率超過 1/4，那就重復(fù)步驟（1）;

1.1.4、 Redis 中所有的 key 在同一時間過期了，會出現(xiàn)怎樣的結(jié)果

• Redis 會持續(xù)掃描過期字典(循環(huán)多次)，直到過期字典中過期的key 變得稀疏，才會停止(循環(huán)次數(shù)明顯下降)。
• 這就會導(dǎo)致線上讀寫請求出現(xiàn)明顯的卡頓現(xiàn)象。導(dǎo)致這種卡頓的另外一種原因是內(nèi)存管理器需要頻繁回收內(nèi)存頁，這也會產(chǎn)生一定的 CPU 消耗。
• 所以業(yè)務(wù)開發(fā)人員一定要注意過期時間，如果有大批量的 key 過期，要給過期時間設(shè)置一個隨機范圍，而不能全部在同一時間過期。

1.1.5、從庫的過期策略

• 從庫不會進行過期掃描，從庫對過期的處理是被動的。主庫在 key 到期時，會在 AOF 文件里增加一條 del 指令，同步到所有的從庫，從庫通過執(zhí)行這條 del 指今來刪除過期的 key。
• 因為指令同步是異步進行的，所以主庫過期的key 的 del 指令沒有及時同步到從庫的話，會出現(xiàn)主從數(shù)據(jù)的不一致，主庫沒有的數(shù)據(jù)在從庫里還存在，比如上-節(jié)的集群環(huán)境分布式鎖的算法漏洞就是因為這個同步延遲產(chǎn)生的。

1.2、惰性刪除

• 所謂惰性策略就是在客戶端訪問這個kev的時候，redis對key的過期時間進行檢查，如果過期了就立即刪除，不會給你返回任何東西。
• 定期刪除可能會導(dǎo)致很多過期kev到了時間并沒有被刪除。所以就有了惰性刪除。假如你的過期 key，靠定期刪除沒有被刪除掉，還停留在內(nèi)存里，除非你的系統(tǒng)去查一下那個 key，才會被redis給刪除掉。
• 這就是所謂的惰性刪除，即當(dāng)你主動去查過期的key時,如果發(fā)現(xiàn)key過期了,就立即進行刪除,不返回任何東西

1.3、定時刪除和惰性刪除的總結(jié)

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

二、緩存淘汰算法

2.1、緩存淘汰算法概述

2.1.1、概述

• 當(dāng) Redis 內(nèi)存超出物理內(nèi)存限制時，內(nèi)存的數(shù)據(jù)會開始和磁盤產(chǎn)生頻繁的交換(swap)。
• 交換會讓 Redis 的性能急劇下降，對于訪問量比較頻繁的 Redis 來說，這樣龜速的存取效率基本上等于不可用。

2.1.2、maxmemory

• 在生產(chǎn)環(huán)境中我們是不允許 Redis 出現(xiàn)交換行為的，為了限制最大使用內(nèi)存，Redis 提供了配置參數(shù)maxmemory 來限制內(nèi)存超出期望大小。
• 當(dāng)實際內(nèi)存超出 maxmemory 時，Redis 提供了幾種可選策略(maxmemory-policy) 來讓用戶自己決定該如何騰出新的空間以繼續(xù)提供讀寫服務(wù)。

2.2、緩存淘汰算法機制

2.2.1、Noeviction

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

2.2.2、volatile-Iru

• volatile-lru 嘗試淘汰設(shè)置了過期時間的key，最少使用的 key 優(yōu)先被淘汰。
• 沒有設(shè)置過期時間的 key 不會被淘汰，這樣可以保證需要持久化的數(shù)據(jù)不會突然丟失。

2.2.3、volatile-ttl

• voatie-ttl 跟上面一樣，除了淘汰的策略不是 LRU，而是key 的剩余壽命ttl的值，ttl 越小越優(yōu)先被淘汰

2.2.4、volatile-random

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

2.2.5、allkeys-lru

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

2.2.6、allkeys-random

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

2.3、緩存淘汰算法總結(jié)

• volatile-xxx 策略只會針對帶過期時間的key 進行淘汰。
• allkeys-xxx 策略會對所有的 key 進行淘汰。
• 如果你只是拿 Redis 做緩存，那應(yīng)該使用 allkeys-xxx，客戶端寫緩存時不必攜帶過期時間。
• 如果你還想同時使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，這樣可以保留沒有設(shè)置過期時間的 key，它們是永久的 key 不會被LRU 算法淘汰。

2.4、LRU 算法概述

• 實現(xiàn) LRU 算法除了需要key/value 字典外，還需要附加一個鏈表，鏈表中的元素按照一定的順序進行排列。當(dāng)空間滿的時候，會踢掉鏈表尾部的元素。當(dāng)字典的某個元素被訪問時，它在鏈表中的位置會被移動到表頭。所以銷表的元素排列順序就是元素最近被訪問的時間順序。
• 位于鏈表尾部的元素就是不被重用的元素，所以會被踢掉。位于表頭的元素就是最近剛剛被人用過的元素，所以暫時不會被踢。

2.5、近似 LRU 算法概述

• Redis 使用的是一種近似 LRU 算法，它跟 LRU 算法還不太一樣。之所以不使用 LRU 算法，是因為需要消耗大量的額外的內(nèi)存，需要對現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)進行較大的改造。
• 近似LRU 算法則很簡單，在現(xiàn)有數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)上使用隨機采樣法來淘汰元素，能達到和 LRU 算法非常近似的效果。Redis 為實現(xiàn)近似LRU 算法，它給每個 key 增加了一個額外的小字段，這個字段的長度是 24 個 bit，也就是最后一次被訪問的時間戳。
• 當(dāng) Redis 執(zhí)行寫操作時，發(fā)現(xiàn)內(nèi)存超出maxmemory，就會執(zhí)行一次 LRU 淘汰算法。這個算法也很簡單，就是隨機采樣出 5可以配置maxmemory-samples) 個 key，然后淘汰掉最舊的 key，如果淘汰后內(nèi)存還是超出maxmemory，那就繼續(xù)隨機采樣淘汰，直到內(nèi)存低于 maxmemory 為止。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。