本文對redis的過時處理機制作個簡單的概述，讓你們有個基本的認識。redis
Redis中有個設置時間過時的功能，即對存儲在redis數據庫中的值能夠設置一個過時時間。做爲一個緩存數據庫，這是很是實用的。如咱們通常項目中的token或者一些登陸信息，尤爲是短信驗證碼都是有時間限制的，按照傳統的數據庫處理方式，通常都是本身判斷過時，這樣無疑會嚴重影響項目性能。數據庫
1、有效時間設置：
redis對存儲值的過時處理其實是針對該值的鍵（key）處理的，即時間的設置也是設置key的有效時間。Expires字典保存了全部鍵的過時時間，Expires也被稱爲過時字段。
四種處理策略緩存
EXPIRE 將key的生存時間設置爲ttl秒
PEXPIRE 將key的生成時間設置爲ttl毫秒
EXPIREAT 將key的過時時間設置爲timestamp所表明的的秒數的時間戳
PEXPIREAT 將key的過時時間設置爲timestamp所表明的的毫秒數的時間戳
其實以上幾種處理方式都是根據PEXPIREAT來實現的，設置生存時間的時候是redis內部計算好時間以後在內存處理的，最終的處理都會轉向PEXPIREAT。
一、2兩種方式是設置一個過時的時間段，就是我們處理驗證碼最經常使用的策略，設置三分鐘或五分鐘後失效，把分鐘數轉換成秒或毫秒存儲到redis中。
三、4兩種方式是指定一個過時的時間 ，好比優惠券的過時時間是某年某月某日，只是單位不同。服務器
2、過時處理
過時鍵的處理就是把過時鍵刪除，這裏的操做主要是針對過時字段處理的。
Redis中有三種處理策略：定時刪除、惰性刪除和按期刪除。性能
定時刪除：在設置鍵的過時時間的時候建立一個定時器，當過時時間到的時候立馬執行刪除操做。不過這種處理方式是即時的，無論這個時間內有多少過時鍵，無論服務器如今的運行情況，都會立馬執行，因此對CPU不是很友好。
惰性刪除：惰性刪除策略不會在鍵過時的時候立馬刪除，而是當外部指令獲取這個鍵的時候纔會主動刪除。處理過程爲：接收get執行、判斷是否過時（這裏按過時判斷）、執行刪除操做、返回nil（空）。
按期刪除：按期刪除是設置一個時間間隔，每一個時間段都會檢測是否有過時鍵，若是有執行刪除操做。這個概念應該很好理解。
看完上面三種策略後能夠得出如下結論：
4. 一、3爲主動刪除，2爲被動刪除。
5. 1是實時執行的，對CPU不是很友好，可是這在最大程度上釋放了內存，因此這種方式算是一種內存優先優化策略。
6. 二、3爲被動刪除，因此過時鍵應該會存在必定的時間，這樣就使得過時鍵不會被立馬刪除，仍然佔用着內存。可是惰性刪除的時候通常是單個刪除，相對來講對CPU是友好的。
7. 按期鍵這種刪除策略是一種讓人很蛋疼的策略，它既有避免一、2兩種策略劣勢的可能，也有同時發生一、2兩種策略劣勢的可能。若是按期刪除執行的過於頻繁就可能會演變成定時刪除，若是執行的過少就有可能形成過多過時鍵未被刪除而佔用過多內存，若是時間的設置不是太好，既可能佔用過多內存又同時對CPU產生很差的影響。因此。使用按期刪除的時候必定要把握好這個刪除的時間點。存在即爲合理，既然開發的時候有這種策略，就說明按期刪除仍是有他的優點的，具體你們能夠本身琢磨。優化
3、主從服務器刪除過時鍵處理
參考書上說的有三種：RDB持久化、AOF持久化和複製功能。.net
RDB：
1. 主服務器模式運行在載入RDB文件時，程序會檢查文件中的鍵，只會加載未過時的，過時的會被忽略，因此RDB模式下過時鍵不會對主服務器產生影響。
2. 從服務器運行載入RDB文件時，會載入全部鍵，包括過時和未過時。當主服務器進行數據同步的時候，從服務器的數據會被清空，因此RDB文件的過時鍵通常不會對從服務器產生影響。設計
AOF：
AOF文件不會受過時鍵的影響。若是有過時鍵未被刪除，會執行如下動做：
客戶端請求時（過時鍵）：blog
從數據庫充刪除被訪問的過時鍵；
追加一條DEL 命令到AOF文件；
向執行請求的客戶端回覆nil（空）。
複製：token
主服務器刪除過時鍵以後，向從服務器發送一條DEL指令，告知刪除該過時鍵。
從服務器接收到get指令的時候不會對過時鍵進行處理，只會當作未過時鍵同樣返回。（爲了保持主從服務器數據的一致性）
從服務器只有接到主服務器發送的DEL指令後纔會刪除過時鍵。
參考書籍：《Redis設計與實現》黃健宏著--------------------- 版權聲明：本文爲CSDN博主「月未明」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/qq_35981283/article/details/70156422