大家都應該知道的Redis過期鍵與過期策略

今天，我和大家分享一篇關于 Redis 有關過期鍵的內(nèi)容，主要有四個內(nèi)容：

• 如何設置過期鍵
• 如何取消設置的過期時間
• 過期鍵的過期策略是怎樣的
• RDB、AOF 和復制對過期鍵的處理又是怎樣的

設置鍵的生存時間或過期時間

redis 一共有 4 個命令來設置鍵的生存時間（可以存活多久）或過期時間（什么時候被刪除）

• expire key> ttl>：將 key 的生存時間設置為 ttl 秒
• pexpire key> ttl>：將 key 的生存時間設置為 ttl 毫秒
• expireat key> timestamp>：將 key 的過期時間設置為 timestamp 所指定的秒數(shù)時間戳
• pexpireat key> ttl>：將 key 的過期時間設置為 timestamp 所指定的毫秒數(shù)時間戳

上述四種命令本質(zhì)上都是通過 pexpireat 命令來實現(xiàn)的。

例子：
127.0.0.1:6379> set a test
OK
127.0.0.1:6379> EXPIRE a 5
(integer) 1
127.0.0.1:6379> get a // 距離設置生存時間命令的 5 秒內(nèi)執(zhí)行
"test"
127.0.0.1:6379> get a // 距離設置生存時間命令的 5 秒后執(zhí)行
(nil)

127.0.0.1:6379> set b 12
OK
127.0.0.1:6379> EXPIREAT b 1545569500
(integer) 1
127.0.0.1:6379> time
1) "1545569486"
2) "108616"
127.0.0.1:6379> get b // 距離設置 1545569500 所指定的秒數(shù)時間戳內(nèi)執(zhí)行
"12"
127.0.0.1:6379> time
1) "1545569506"
2) "208567"
127.0.0.1:6379> get b // 距離設置 1545569500 所指定的秒數(shù)時間戳后執(zhí)行
(nil)

如果自己不小心設置錯了過期時間，那么我們可以刪除先前的過期時間

移除過期時間

persist key> 命令可以移除一個鍵的過期時間，舉個栗子：

127.0.0.1:6379> EXPIRE c 1000
(integer) 1
127.0.0.1:6379> ttl c // 有過期時間
(integer) 9996
127.0.0.1:6379> PERSIST c
(integer) 1
127.0.0.1:6379> ttl c // 無過期時間
(integer) -1

PS：ttl 是以秒為單位，返回鍵的剩余生存時間；同理還有 pttl 命令是以毫秒為單位，返回鍵的剩余生存時間

此時，如果我們沒有移除過期時間，那么如果一個鍵過期了，那它什么時候會被刪除呢？

這個問題就會有以下三種答案了，它們分別代表三種不同的刪除策略

過期鍵的刪除策略

定時刪除

在設置鍵的過期時間的同時，創(chuàng)建一個定時器，讓定時器在鍵的過期時間來臨時，立即執(zhí)行對鍵的刪除操作。

優(yōu)點：對內(nèi)存最友好的?？梢约皶r釋放鍵所占用的內(nèi)存。

缺點：對 CPU 不友好。特別在過期鍵比較多的情況下，刪除過期鍵會占用相當一部分 CPU 時間。同時在內(nèi)存不緊張，CPU 緊張的情況下，將 CPU 用在刪除和當前任務不想關的過期鍵上，無疑會對服務器響應時間和吞吐量造成影響。

惰性刪除

放任鍵過期不管，但是每次從鍵空間中讀寫鍵時，都會檢查取得的鍵是否過期。如果過期就刪除該刪，否則就返回該鍵。（PS：鍵空間是一個保存了數(shù)據(jù)庫所有鍵值對的數(shù)據(jù)結構）

優(yōu)點：對 CPU 最友好。只有在操作的時候進行過期檢查，刪除的目標僅限于當前需要處理的鍵，不會在刪除其他無關本次操作的過期鍵上花費任何 CPU 時間。

缺點：對內(nèi)存不友好。這個十分容易理解了，鍵過期了，但因為一直沒有被訪問到，所以一直保留著（除非手動執(zhí)行 flushdb 操來于清空當前數(shù)據(jù)庫中的所有 key。），相當于內(nèi)存泄漏。

定期刪除

每隔一段時間，程序就對數(shù)據(jù)庫進行檢查，刪除里面的過期鍵。至于要刪除多少過期鍵，以及檢查多少數(shù)據(jù)庫，則有算法決定。

該策略是上述兩種策略的折中方案，需要通過實際情況，來設置刪除操作的執(zhí)行時長和頻率。

明白了過期鍵的刪除策略后，那 redis 服務器又是采用什么策略來刪除過期鍵的呢？

實際上，Redis 服務器使用的是惰性刪除和定期刪除兩種策略，通過配合使用，服務器可以很好的平衡 CPU 和內(nèi)存。

其中惰性刪除為 redis 服務器內(nèi)置策略。而定期刪除可以通過以下兩種方式設置：

• 配置 redis.conf 的 hz 選項，默認為10 （即 1 秒執(zhí)行 10 次，值越大說明刷新頻率越快，對 Redis 性能損耗也越大）
• 配置 redis.conf 的 maxmemory 最大值，當已用內(nèi)存超過 maxmemory 限定時，就會觸發(fā)主動清理策略

RDB 對過期鍵的處理

生成 RDB 文件

程序會被數(shù)據(jù)庫中的鍵進行檢查，過期的鍵不會被保存到新創(chuàng)建的 RDB 文件中。因此數(shù)據(jù)庫中的過期鍵不會對生成新的 RDB 文件造成影響

載入 RDB 文件

這里需要分情況說明：

• 如果服務器以主服務器模式運行，則在載入 RDB 文件時，程序會對文件中保存的鍵進行檢查，過期鍵不會被載入到數(shù)據(jù)庫中。所以過期鍵不會對載入 RDB 文件的主服務器造成影響。
• 如果服務器以從服務器模式運行，則在載入 RDB 文件時，不論鍵是否過期都會被載入到數(shù)據(jù)庫中。但由于主從服務器在進行數(shù)據(jù)同步時，從服務器的數(shù)據(jù)會被清空。所以一般來說，過期鍵對載入 RDB 文件的從服務器也不會造成影響。

AOF 對過期鍵的處理

AOF 文件寫入

當服務器以 AOF 持久化模式運行時，如果數(shù)據(jù)庫某個過期鍵還沒被刪除，那么 AOF 文件不會因為這個過期鍵而產(chǎn)生任何影響，依舊保留。

而當過期鍵被刪除后，那么程序會向 AOF 文件追加一條 DEL 命令來顯式地記錄該鍵被刪除。

AOF 重寫

執(zhí)行 AOF 重寫過程中，也會被數(shù)據(jù)庫的鍵進行檢查，已過期的鍵不會被保存到重寫后的 AOF 文件中。因此不會對 AOF 重寫造成影響

復制對過期鍵的處理

當服務器運行在復制模式下，由主服務器來控制從服務器的刪除過期鍵動作，目的是保證主從服務器數(shù)據(jù)的一致性。

那到底是怎么控制的呢？

• 主服務器刪除一個過期鍵后，會向所有從服務器發(fā)送一個 DEL 命令，告訴從服務器刪除這個過期鍵
• 從服務器接受到命令后，刪除過期鍵

PS:從服務器在接收到客戶端對過期鍵的讀命令時，依舊會返回該鍵對應的值給客戶端，而不會將其刪除。

總結

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。