大家都應該知道的Redis過期鍵與過期策略
今天,我和大家分享一篇關於 Redis 有關過期鍵的內容,主要有四個內容:
- 如何設定過期鍵
- 如何取消設定的過期時間
- 過期鍵的過期策略是怎樣的
- RDB、AOF 和複製對過期鍵的處理又是怎樣的
設定鍵的生存時間或過期時間
redis 一共有 4 個命令來設定鍵的生存時間(可以存活多久)或過期時間(什麼時候被刪除)
- expire <key> <ttl>:將 key 的生存時間設定為 ttl 秒
- pexpire <key> <ttl>:將 key 的生存時間設定為 ttl 毫秒
- expireat <key> <timestamp>:將 key 的過期時間設定為 timestamp 所指定的秒數時間戳
- pexpireat <key> <ttl>:將 key 的過期時間設定為 timestamp 所指定的毫秒數時間戳
上述四種命令本質上都是通過 pexpireat 命令來實現的。
例子: 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 秒內執行 "test" 127.0.0.1:6379> get a // 距離設定生存時間命令的 5 秒後執行 (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 所指定的秒數時間戳內執行 "12" 127.0.0.1:6379> time 1) "1545569506" 2) "208567" 127.0.0.1:6379> get b // 距離設定 1545569500 所指定的秒數時間戳後執行 (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 命令是以毫秒為單位,返回鍵的剩餘生存時間
此時,如果我們沒有移除過期時間,那麼如果一個鍵過期了,那它什麼時候會被刪除呢?
這個問題就會有以下三種答案了,它們分別代表三種不同的刪除策略
過期鍵的刪除策略
定時刪除
在設定鍵的過期時間的同時,建立一個定時器,讓定時器在鍵的過期時間來臨時,立即執行對鍵的刪除操作。
優點:對記憶體最友好的。可以及時釋放鍵所佔用的記憶體。
缺點:對 CPU 不友好。特別在過期鍵比較多的情況下,刪除過期鍵會佔用相當一部分 CPU 時間。同時在記憶體不緊張,CPU 緊張的情況下,將 CPU 用在刪除和當前任務不想關的過期鍵上,無疑會對伺服器響應時間和吞吐量造成影響。
惰性刪除
放任鍵過期不管,但是每次從鍵空間中讀寫鍵時,都會檢查取得的鍵是否過期。如果過期就刪除該刪,否則就返回該鍵。(PS:鍵空間是一個儲存了資料庫所有鍵值對的資料結構)
優點:對 CPU 最友好。只有在操作的時候進行過期檢查,刪除的目標僅限於當前需要處理的鍵,不會在刪除其他無關本次操作的過期鍵上花費任何 CPU 時間。
缺點:對記憶體不友好。這個十分容易理解了,鍵過期了,但因為一直沒有被訪問到,所以一直保留著(除非手動執行 flushdb 操來於清空當前資料庫中的所有 key。),相當於記憶體洩漏。
定期刪除
每隔一段時間,程式就對資料庫進行檢查,刪除裡面的過期鍵。至於要刪除多少過期鍵,以及檢查多少資料庫,則有演算法決定。
該策略是上述兩種策略的折中方案,需要通過實際情況,來設定刪除操作的執行時長和頻率。
明白了過期鍵的刪除策略後,那 redis 伺服器又是採用什麼策略來刪除過期鍵的呢?
實際上,Redis 伺服器使用的是惰性刪除和定期刪除兩種策略,通過配合使用,伺服器可以很好的平衡 CPU 和記憶體。
其中惰性刪除為 redis 伺服器內建策略。而定期刪除可以通過以下兩種方式設定:
- 配置 redis.conf 的 hz 選項,預設為10 (即 1 秒執行 10 次,值越大說明重新整理頻率越快,對 Redis 效能損耗也越大)
- 配置 redis.conf 的 maxmemory 最大值,當已用記憶體超過 maxmemory 限定時,就會觸發主動清理策略
RDB 對過期鍵的處理
生成 RDB 檔案
程式會被資料庫中的鍵進行檢查,過期的鍵不會被儲存到新建立的 RDB 檔案中。因此資料庫中的過期鍵不會對生成新的 RDB 檔案造成影響
載入 RDB 檔案
這裡需要分情況說明:
- 如果伺服器以主伺服器模式執行,則在載入 RDB 檔案時,程式會對檔案中儲存的鍵進行檢查,過期鍵不會被載入到資料庫中。所以過期鍵不會對載入 RDB 檔案的主伺服器造成影響。
- 如果伺服器以從伺服器模式執行,則在載入 RDB 檔案時,不論鍵是否過期都會被載入到資料庫中。但由於主從伺服器在進行資料同步時,從伺服器的資料會被清空。所以一般來說,過期鍵對載入 RDB 檔案的從伺服器也不會造成影響。
AOF 對過期鍵的處理
AOF 檔案寫入
當伺服器以 AOF 持久化模式執行時,如果資料庫某個過期鍵還沒被刪除,那麼 AOF 檔案不會因為這個過期鍵而產生任何影響,依舊保留。
而當過期鍵被刪除後,那麼程式會向 AOF 檔案追加一條 DEL 命令來顯式地記錄該鍵被刪除。
AOF 重寫
執行 AOF 重寫過程中,也會被資料庫的鍵進行檢查,已過期的鍵不會被儲存到重寫後的 AOF 檔案中。因此不會對 AOF 重寫造成影響
複製對過期鍵的處理
當伺服器執行在複製模式下,由主伺服器來控制從伺服器的刪除過期鍵動作,目的是保證主從伺服器資料的一致性。
那到底是怎麼控制的呢?
- 主伺服器刪除一個過期鍵後,會向所有從伺服器傳送一個 DEL 命令,告訴從伺服器刪除這個過期鍵
- 從伺服器接受到命令後,刪除過期鍵
PS:從伺服器在接收到客戶端對過期鍵的讀命令時,依舊會返回該鍵對應的值給客戶端,而不會將其刪除。
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對我們的支援。