作為一種定期清理無效數據的重要機制，主鍵失效存在於大多數緩存系統中，Redis 也不例外。在 Redis 提供的諸多命令中，EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT 以及 SETEX 和 PSETEX 均可以用來設置一條 Key-Value 對的失效時間，而一條 Key-Value 對一旦被關聯了失效時間就會在到期后自動刪除（或者說變得無法訪問更為准確）。可以說，主鍵失效這個概念還是比較容易理解的，但是在具體實現到 Redis 中又是如何呢？
常用方式: （timestamp為unix時間戳（例如：timestamp=1499788800 表示將在2017.07.12過期））
1.EXPRISE key seconds //將key的生存時間設置為ttl秒
2.PEXPIRE key milliseconds //將key的生成時間設置為ttl毫秒
3.EXPIREAT key timestamp //將key的過期時間設置為timestamp所代表的的秒數的時間戳
4.PEXPIREAT key milliseconds-timestamp //將key的過期時間設置為timestamp所代表的的毫秒數的時間戳
應用場景：1、2兩種方式是設置一個過期的時間段，就是咱們處理驗證碼最常用的策略，設置三分鍾或五分鍾后失效，把分鍾數轉換成秒或毫秒存儲到Redis中。
3、4兩種方式是指定一個過期的時間 ，比如優惠券的過期時間是某年某月某日，只是單位不一樣。
SETEX KEY_NAME TIMEOUT VALUE 設置可過期的鍵值
1. RedisDB 結構體
typedef struct redisDb {
dict *dict;
dict *expires;
dict *blocking_keys;
dict *ready_keys;
dict *watched_keys;
int id;
} redisDb;
Redis 中關於數據庫的結構體定義，這個結構體定義中除了 id 以外都是指向字典的指針，其中我們只看 dict 和 expries，前者用來維護一個 Redis 數據庫中包含的所有 Key-Value 對（其結構可以理解為 dict[key]:value，即主鍵與值之間的映射），后者則用於維護一個 Redis 數據庫中設置了失效時間的主鍵（其結構可以理解為 expires[key]:timeout，即主鍵與失效時間的映射）。當我們使用 SETEX 和 PSETEX 命令向系統插入數據時，Redis 首先將 Key 和 Value 添加到 dict 這個字典表中，然后將 Key 和失效時間添加到 expires 這個字典表中。當我們使用 EXPIRE、EXPIREAT、PEXPIRE 和 PEXPIREAT 命令設置一個主鍵的失效時間時，Redis 首先到 dict 這個字典表中查找要設置的主鍵是否存在，如果存在就將這個主鍵和失效時間添加到 expires 這個字典表。簡單地總結來說就是，設置了失效時間的主鍵和具體的失效時間全部都維護在 expires 這個字典表中
2. 過期策略
2.1 定時刪除
- 定義：在設置key的過期時間的同時，為該key創建一個定時器，讓定時器在key的過期時間來臨時，對key進行刪除
- 優點：保證內存的盡快釋放
- 缺點：若過期key很多，刪除這些key會占用很多的CPU時間，在CPU時間緊張的情況下，CPU不能把所有的時間用來做要緊的事兒，還需要去花時間刪除這些key，定時器的創建耗時，若為每一個設置過期時間的key創建一個定時器（將會有大量的定時器產生），性能影響嚴重
2.2 惰性刪除
- 定義：key過期的時候不刪除，每次從數據庫獲取key的時候檢查是否過期，若過期，則刪除，返回null。
- 優點：刪除操作只發生在從數據庫取出key的時候發生，而且只刪除當前key，所以對CPU時間的占用是比較少的，而且此時的刪除是已經到了非做不可的地步
- 缺點：若大量的key在超出超時時間后，很久一段時間內，都沒有被獲取過，那么可能發生內存泄露（無用的垃圾占用了大量的內存）
2.3 定期刪除
- 定義：每隔一段時間進行一次刪除過期key的操作
- 優點：通過限制刪除操作的時長和頻率，來減少刪除操作對CPU時間的占用--處理"定時刪除"的缺點， 解決惰性刪除的缺點
- 缺點：在內存友好方面不如 定時刪除， 在CPU時間友好方面，不如惰性刪除
3. Redis 使用的過期刪除策略
3. 1 消極方法 - 惰性刪除
int expireIfNeeded(redisDb *db, robj *key) {
// 獲取主鍵的失效時間
long long when = getExpire(db, key);
//假如失效時間為負數，說明該主鍵未設置失效時間（失效時間默認為-1），直接返回0
if (when < 0) return 0;
//假如Redis服務器正在從RDB文件中加載數據，暫時不進行失效主鍵的刪除，直接返回0
if (server.loading) return 0;
//假如當前的Redis服務器是作為Slave運行的，那么不進行失效主鍵的刪除，因為Slave
//上失效主鍵的刪除是由Master來控制的，但是這里會將主鍵的失效時間與當前時間進行
//一下對比，以告知調用者指定的主鍵是否已經失效了
if (server.masterhost != NULL) {
return mstime() > when;
}
//如果以上條件都不滿足，就將主鍵的失效時間與當前時間進行對比，如果發現指定的主鍵
//還未失效就直接返回0
if (mstime() <= when) return 0;
//如果發現主鍵確實已經失效了，那么首先更新關於失效主鍵的統計個數，然后將該主鍵失
//效的信息進行廣播，最后將該主鍵從數據庫中刪除
server.stat_expiredkeys++;
propagateExpire(db, key);
return dbDelete(db, key);
}
這個函數在任何訪問數據的函數中都會被調用，也就是說 Redis 在實現 GET、MGET、HGET、LRANGE 等所有涉及到讀取數據的命令時都會調用它，它存在的意義就是在讀取數據之前先檢查一下它有沒有失效，如果失效了就刪除它。
void propagateExpire(redisDb *db, robj *key) {
robj *argv[2];
//shared.del是在Redis服務器啟動之初就已經初始化好的一個常用Redis對象，即DEL命令
argv[0] = shared.del;
argv[1] = key;
incrRefCount(argv[0]);
incrRefCount(argv[1]);
//檢查Redis服務器是否開啟了AOF，如果開啟了就為失效主鍵記錄一條DEL日志
if (server.aof_state != REDIS_AOF_OFF)
feedAppendOnlyFile(server.delCommand,db->id,argv,2);
//檢查Redis服務器是否擁有Slave，如果是就向所有Slave發送DEL失效主鍵的命令，這就是
//上面expireIfNeeded函數中發現自己是Slave時無需主動刪除失效主鍵的原因了，因為它
//只需聽從Master發送過來的命令就OK了
if (listLength(server.slaves))
replicationFeedSlaves(server.slaves,db->id,argv,2);
decrRefCount(argv[0]);
decrRefCount(argv[1]);
}
需要說明的是在 expireIfNeeded 函數中調用的另外一個函數 propagateExpire，這個函數用來在正式刪除失效主鍵之前廣播這個主鍵已經失效的信息，這個信息會傳播到兩個目的地：一個是發送到 AOF文件，將刪除失效主鍵的這一操作以 DEL Key 的標准命令格式記錄下來；另一個就是發送到當前 Redis 服務器的所有 Slave，同樣將刪除失效主鍵的這一操作以 DEL Key 的標准命令格式告知這些 Slave 刪除各自的失效主鍵。從中我們可以知道，所有作為 Slave 來運行的 Redis 服務器並不需要通過消極方法來刪除失效主鍵，它們只需要對 Master 唯命是從就 OK 了！
3.2 積極方法 - 定期刪除
以上我們通過對 expireIfNeeded 函數的介紹了解了 Redis 是如何以一種消極的方式刪除失效主鍵的，但是僅僅通過這種方式顯然是不夠的，因為如果某些失效的主鍵遲遲等不到再次訪問的話，Redis 就永遠不會知道這些主鍵已經失效，也就永遠也不會刪除它們了，這無疑會導致內存空間的浪費。因此，Redis 還准備了一招積極的刪除方法，該方法利用 Redis 的時間事件來實現，即每隔一段時間就中斷一下完成一些指定操作，其中就包括檢查並刪除失效主鍵。這里我們說的時間事件的回調函數就是 serverCron，它在 Redis 服務器啟動時創建，每秒的執行次數由宏定義 REDIS_DEFAULT_HZ 來指定，默認每秒鍾執行10次。以下代碼給出該時間事件創建時的程序代碼，該代碼在 redis.c文件的 initServer 函數中。實際上，serverCron 這個回調函數不僅要進行失效主鍵的檢查與刪除，還要進行統計信息的更新、客戶端連接超時的控制、BGSAVE 和 AOF 的觸發等等，這里我們僅關注刪除失效主鍵的實現，也就是函數 activeExpireCycle。
if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
redisPanic("create time event failed");
exit(1);
}
函數 activeExpireCycle 的實現及其詳細描述，其主要實現原理就是遍歷處理 Redis 服務器中每個數據庫的 expires 字典表中，從中嘗試着隨機抽樣 REDIS_EXPIRELOOKUPS_PER_CRON（默認值為10）個設置了失效時間的主鍵，檢查它們是否已經失效並刪除掉失效的主鍵，如果失效的主鍵個數占本次抽樣個數的比例超過25%，Redis 會認為當前數據庫中的失效主鍵依然很多，所以它會繼續進行下一輪的隨機抽樣和刪除，直到剛才的比例低於25%才停止對當前數據庫的處理，轉向下一個數據庫。這里我們需要注意的是，activeExpireCycle 函數不會試圖一次性處理Redis中的所有數據庫，而是最多只處理 REDIS_DBCRON_DBS_PER_CALL（默認值為16），此外 activeExpireCycle 函數還有處理時間上的限制，不是想執行多久就執行多久，凡此種種都只有一個目的，那就是避免失效主鍵刪除占用過多的CPU資源
void activeExpireCycle(void) {
static unsigned int current_db = 0;
static int timelimit_exit = 0;
unsigned int j, iteration = 0;
unsigned int dbs_per_call = REDIS_DBCRON_DBS_PER_CALL
long long start = ustime(), timelimit;
if (dbs_per_call) > server.dbnum || timelimit_exit)
db_per_call = server.dbnum;
}
void activeExpireCycle(void) {
//因為每次調用activeExpireCycle函數不會一次性檢查所有Redis數據庫，所以需要記錄下
//每次函數調用處理的最后一個Redis數據庫的編號，這樣下次調用activeExpireCycle函數
//還可以從這個數據庫開始繼續處理，這就是current_db被聲明為static的原因，而另外一
//個變量timelimit_exit是為了記錄上一次調用activeExpireCycle函數的執行時間是否達
//到時間限制了，所以也需要聲明為static
static unsigned int current_db = 0;
static int timelimit_exit = 0;
unsigned int j, iteration = 0;
//每次調用activeExpireCycle函數處理的Redis數據庫個數為REDIS_DBCRON_DBS_PER_CALL
unsigned int dbs_per_call = REDIS_DBCRON_DBS_PER_CALL;
long long start = ustime(), timelimit;
//如果當前Redis服務器中的數據庫個數小於REDIS_DBCRON_DBS_PER_CALL，則處理全部數據庫，
//如果上一次調用activeExpireCycle函數的執行時間達到了時間限制，說明失效主鍵較多，也
//會選擇處理全部數據庫
if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;
//執行activeExpireCycle函數的最長時間（以微秒計），其中REDIS_EXPIRELOOKUPS_TIME_PERC
//是單位時間內能夠分配給activeExpireCycle函數執行的CPU時間比例，默認值為25，server.hz
//即為一秒內activeExpireCycle的調用次數，所以這個計算公式更明白的寫法應該是這樣的，即
(1000000 * (REDIS_EXPIRELOOKUPS_TIME_PERC / 100)) / server.hz
timelimit = 1000000*REDIS_EXPIRELOOKUPS_TIME_PERC/server.hz/100;
timelimit_exit = 0;
if (timelimit <= 0) timelimit = 1;
//遍歷處理每個Redis數據庫中的失效數據
for (j = 0; j < dbs_per_call; j++) {
int expired;
redisDb *db = server.db+(current_db % server.dbnum);
//此處立刻就將current_db加一，這樣可以保證即使這次無法在時間限制內刪除完所有當前
//數據庫中的失效主鍵，下一次調用activeExpireCycle一樣會從下一個數據庫開始處理，
//從而保證每個數據庫都有被處理的機會
current_db++;
//開始處理當前數據庫中的失效主鍵
do {
unsigned long num, slots;
long long now;
//如果expires字典表大小為0，說明該數據庫中沒有設置失效時間的主鍵，直接檢查下
//一數據庫
if ((num = dictSize(db->expires)) == 0) break;
slots = dictSlots(db->expires);
now = mstime();
//如果expires字典表不為空，但是其填充率不足1%，那么隨機選擇主鍵進行檢查的代價
//會很高，所以這里直接檢查下一數據庫
if (num && slots > DICT_HT_INITIAL_SIZE &&
(num*100/slots < 1)) break;
expired = 0;
//如果expires字典表中的entry個數不足以達到抽樣個數，則選擇全部key作為抽樣樣本
if (num > REDIS_EXPIRELOOKUPS_PER_CRON)
num = REDIS_EXPIRELOOKUPS_PER_CRON;
while (num--) {
dictEntry *de;
long long t;
//隨機獲取一個設置了失效時間的主鍵，檢查其是否已經失效
if ((de = dictGetRandomKey(db->expires)) == NULL) break;
t = dictGetSignedIntegerVal(de);
if (now > t) {
//發現該主鍵確實已經失效，刪除該主鍵
sds key = dictGetKey(de);
robj *keyobj = createStringObject(key,sdslen(key));
//同樣要在刪除前廣播該主鍵的失效信息
propagateExpire(db,keyobj);
dbDelete(db,keyobj);
decrRefCount(keyobj);
expired++;
server.stat_expiredkeys++;
}
}
//每進行一次抽樣刪除后對iteration加一，每16次抽樣刪除后檢查本次執行時間是否
//已經達到時間限制，如果已達到時間限制，則記錄本次執行達到時間限制並退出
iteration++;
if ((iteration & 0xf) == 0 &&
(ustime()-start) > timelimit)
{
timelimit_exit = 1;
return;
}
//如果失效的主鍵數占抽樣數的百分比大於25%，則繼續抽樣刪除過程
} while (expired > REDIS_EXPIRELOOKUPS_PER_CRON/4);
}
}
4. Memcached 刪除失效主鍵的方法與 Redis 有何異同？
Memcache在刪除失效主鍵時也是采用消極方法，即Memcached 內部也不會監視主鍵是否失效，而是在通過Get訪問主鍵時才會檢查是否失效。其次，Memcached 與 Redis 在主鍵失效機制上的最大不同是，Memcached 不會像 Redis 那樣真正地去刪除失效的主鍵，而只是簡單地將失效主鍵占用的空間回收。這樣當有新的數據寫入到系統中時，Memcached 會優先使用那些失效主鍵的空間。如果失效主鍵的空間用光了，Memcached 還可以通過 LRU 機制來回收那些長期得不到訪問的空間，因此 Memcached 並不需要像 Redis 中那樣的周期性刪除操作，這也是由 Memcached 使用的內存管理機制決定的。同時，這里需要指出的是 Redis 在出現 OOM（內存不足） 時同樣可以通過配置maxmemory-policy 這個參數來決定是否采用 LRU機制來回收內存空間。可以在配置文件中配置刪除算法:
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached? You can select among five behavior:
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key accordingly to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys-random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don't expire at all, just return an error on write operations
4.1 Reids中的LRU機制
Redis-LRU-Cache
使用HashMap+雙向鏈表進行淘汰過期鍵。如果按照HashMap和雙向鏈表實現，需要額外的存儲存放 next 和 prev 指針，犧牲比較大的存儲空間，顯然是不划算的。所以Redis采用了一個近似的做法，就是隨機取出若干個key，然后按照訪問時間排序后，淘汰掉最不經常使用的，具體分析如下：
Redis支持和LRU相關淘汰策略包括
- volatile-lru：設置了過期的key參與近似的LRU淘汰策略
- allkeys-lru：所有的key均參與近似的lru淘汰策略
為了支持LRU，Redis 2.8.19中使用了一個全局的LRU時鍾，server.lruclock，定義如下，
#define REDIS_LRU_BITS 24
unsigned lruclock:REDIS_LRU_BITS; /* Clock for LRU eviction */
默認的LRU時鍾的分辨率是1秒，可以通過改變REDIS_LRU_CLOCK_RESOLUTION宏的值來改變，Redis會在serverCron()中調用updateLRUClock定期的更新LRU時鍾，更新的頻率和hz參數有關，默認為100msj檢測一次，如下，
#define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
#define REDIS_LRU_CLOCK_RESOLUTION 1 /* LRU clock resolution in seconds */
void updateLRUClock(void) {
server.lruclock = (server.unixtime / REDIS_LRU_CLOCK_RESOLUTION) &
REDIS_LRU_CLOCK_MAX;
}
Redis會基於server.maxmemory_samples配置選取固定數目的key，然后比較它們的lru訪問時間，然后淘汰最近最久沒有訪問的key，maxmemory_samples的值越大，Redis的近似LRU算法就越接近於嚴格LRU算法，但是相應消耗也變高，對性能有一定影響，樣本值默認為5。
5. Reids的主鍵失效機制會不會影響系統性能？
以下幾種機制大大降低了主鍵失效機制對系統性能的影響。
- 對每次處理數據庫個數限制
- 限制activeExpireCycle 函數在一秒內執行次數 server.hz
- 限制分配給activeExpireCycle函數的CPU時間
- 失效主鍵占抽樣個數的百分比限制
6. 應用 緩存更新的套路
6.1 常規套路 Cache Aside Pattern
- 失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
- 命中：應用程序從cache中取數據，取到后返回
- 更新：先把數據存到數據庫，成功后，在讓緩存失效
參考：