int expireIfNeeded(redisDb *db, robj *key) {
獲取主鍵的失效時(shí)間
long long when = getExpire(db,key);
假如失效時(shí)間為負(fù)數(shù)，說明該主鍵未設(shè)置失效時(shí)間（失效時(shí)間默認(rèn)為-1），直接返回0
if (when < 0) return 0;
假如Redis服務(wù)器正在從RDB文件中加載數(shù)據(jù)，暫時(shí)不進(jìn)行失效主鍵的刪除，直接返回0
if (server.loading) return 0;
假如當(dāng)前的Redis服務(wù)器是作為Slave運(yùn)行的，那么不進(jìn)行失效主鍵的刪除，因?yàn)镾lave
上失效主鍵的刪除是由Master來控制的，但是這里會(huì)將主鍵的失效時(shí)間與當(dāng)前時(shí)間進(jìn)行
一下對比，以告知調(diào)用者指定的主鍵是否已經(jīng)失效了
if (server.masterhost != NULL) {
return mstime() > when;
}
如果以上條件都不滿足，就將主鍵的失效時(shí)間與當(dāng)前時(shí)間進(jìn)行對比，如果發(fā)現(xiàn)指定的主鍵
還未失效就直接返回0
if (mstime() <= when) return 0;
如果發(fā)現(xiàn)主鍵確實(shí)已經(jīng)失效了，那么首先更新關(guān)于失效主鍵的統(tǒng)計(jì)個(gè)數(shù)，然后將該主鍵失
效的信息進(jìn)行廣播，最后將該主鍵從數(shù)據(jù)庫中刪除
server.stat_expiredkeys++;
propagateExpire(db,key);
return dbDelete(db,key);
}
代碼段三：
void propagateExpire(redisDb *db, robj *key) {
robj *argv[2];
shared.del是在Redis服務(wù)器啟動(dòng)之初就已經(jīng)初始化好的一個(gè)常用Redis對象，即DEL命令
argv[0] = shared.del;
argv[1] = key;
incrRefCount(argv[0]);
incrRefCount(argv[1]);
檢查Redis服務(wù)器是否開啟了AOF，如果開啟了就為失效主鍵記錄一條DEL日志
if (server.aof_state != REDIS_AOF_OFF)
feedAppendOnlyFile(server.delCommand,db->id,argv,2);
檢查Redis服務(wù)器是否擁有Slave，如果是就向所有Slave發(fā)送DEL失效主鍵的命令，這就是
上面expireIfNeeded函數(shù)中發(fā)現(xiàn)自己是Slave時(shí)無需主動(dòng)刪除失效主鍵的原因了，因?yàn)樗?/font>
只需聽從Master發(fā)送過來的命令就OK了
if (listLength(server.slaves))
replicationFeedSlaves(server.slaves,db->id,argv,2);
decrRefCount(argv[0]);
decrRefCount(argv[1]);
}
以上我們通過對expireIfNeeded函數(shù)的介紹了解了Redis是如何以一種消極的方式刪除失效主鍵的，但是僅僅通過這種方式顯然是不夠的，因?yàn)槿绻承┦У闹麈I遲遲等不到再次訪問的話，Redis就永遠(yuǎn)不會(huì)知道這些主鍵已經(jīng)失效，也就永遠(yuǎn)也不會(huì)刪除它們了，這無疑會(huì)導(dǎo)致內(nèi)存空間的浪費(fèi)。因此，Redis還準(zhǔn)備了一招積極的刪除方法，該方法利用Redis的時(shí)間事件來實(shí)現(xiàn)，即每隔一段時(shí)間就中斷一下完成一些指定操作，其中就包括檢查并刪除失效主鍵。這里我們說的時(shí)間事件的回調(diào)函數(shù)就是serverCron，它在Redis服務(wù)器啟動(dòng)時(shí)創(chuàng)建，每秒的執(zhí)行次數(shù)由宏定義REDIS_DEFAULT_HZ來指定，默認(rèn)每秒鐘執(zhí)行10次。代碼段四給出該時(shí)間事件創(chuàng)建時(shí)的程序代碼，該代碼在redis.c文件的initServer函數(shù)中。實(shí)際上，serverCron這個(gè)回調(diào)函數(shù)不僅要進(jìn)行失效主鍵的檢查與刪除，還要進(jìn)行統(tǒng)計(jì)信息的更新、客戶端連接超時(shí)的控制、BGSAVE和AOF的觸發(fā)等等，這里我們僅關(guān)注刪除失效主鍵的實(shí)現(xiàn)，也就是函數(shù)activeExpireCycle。
void activeExpireCycle(void) {
因?yàn)槊看握{(diào)用activeExpireCycle函數(shù)不會(huì)一次性檢查所有Redis數(shù)據(jù)庫，所以需要記錄下
每次函數(shù)調(diào)用處理的最后一個(gè)Redis數(shù)據(jù)庫的編號(hào)，這樣下次調(diào)用activeExpireCycle函數(shù)
還可以從這個(gè)數(shù)據(jù)庫開始繼續(xù)處理，這就是current_db被聲明為static的原因，而另外一
個(gè)變量timelimit_exit是為了記錄上一次調(diào)用activeExpireCycle函數(shù)的執(zhí)行時(shí)間是否達(dá)
到時(shí)間限制了，所以也需要聲明為static
static unsigned int current_db = 0;
static int timelimit_exit = 0;
unsigned int j, iteration = 0;
每次調(diào)用activeExpireCycle函數(shù)處理的Redis數(shù)據(jù)庫個(gè)數(shù)為REDIS_DBCRON_DBS_PER_CALL
unsigned int dbs_per_call = REDIS_DBCRON_DBS_PER_CALL;
long long start = ustime(), timelimit;
如果當(dāng)前Redis服務(wù)器中的數(shù)據(jù)庫個(gè)數(shù)小于REDIS_DBCRON_DBS_PER_CALL，則處理全部數(shù)據(jù)庫，
如果上一次調(diào)用activeExpireCycle函數(shù)的執(zhí)行時(shí)間達(dá)到了時(shí)間限制，說明失效主鍵較多，也
會(huì)選擇處理全部數(shù)據(jù)庫
if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;
執(zhí)行activeExpireCycle函數(shù)的最長時(shí)間（以微秒計(jì)），其中REDIS_EXPIRELOOKUPS_TIME_PERC
是單位時(shí)間內(nèi)能夠分配給activeExpireCycle函數(shù)執(zhí)行的CPU時(shí)間比例，默認(rèn)值為25，server.hz
即為一秒內(nèi)activeExpireCycle的調(diào)用次數(shù)，所以這個(gè)計(jì)算公式更明白的寫法應(yīng)該是這樣的，即
(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;
遍歷處理每個(gè)Redis數(shù)據(jù)庫中的失效數(shù)據(jù)
for (j = 0; j < dbs_per_call; j++) {
int expired;
redisDb *db = server.db+(current_db % server.dbnum);
此處立刻就將current_db加一，這樣可以保證即使這次無法在時(shí)間限制內(nèi)刪除完所有當(dāng)前
數(shù)據(jù)庫中的失效主鍵，下一次調(diào)用activeExpireCycle一樣會(huì)從下一個(gè)數(shù)據(jù)庫開始處理，
從而保證每個(gè)數(shù)據(jù)庫都有被處理的機(jī)會(huì)
current_db++;
開始處理當(dāng)前數(shù)據(jù)庫中的失效主鍵
do {
unsigned long num, slots;
long long now;
如果expires字典表大小為0，說明該數(shù)據(jù)庫中沒有設(shè)置失效時(shí)間的主鍵，直接檢查下
一數(shù)據(jù)庫
if ((num = dictSize(db->expires)) == 0) break;
slots = dictSlots(db->expires);
now = mstime();
如果expires字典表不為空，但是其填充率不足1%，那么隨機(jī)選擇主鍵進(jìn)行檢查的代價(jià)
會(huì)很高，所以這里直接檢查下一數(shù)據(jù)庫
if (num && slots > DICT_HT_INITIAL_SIZE &&
(num*100/slots < 1)) break;
expired = 0;
如果expires字典表中的entry個(gè)數(shù)不足以達(dá)到抽樣個(gè)數(shù)，則選擇全部key作為抽樣樣本
if (num > REDIS_EXPIRELOOKUPS_PER_CRON)
num = REDIS_EXPIRELOOKUPS_PER_CRON;
while (num--) {
dictEntry *de;
long long t;
隨機(jī)獲取一個(gè)設(shè)置了失效時(shí)間的主鍵，檢查其是否已經(jīng)失效
if ((de = dictGetRandomKey(db->expires)) == NULL) break;
t = dictGetSignedIntegerVal(de);
if (now > t) {
發(fā)現(xiàn)該主鍵確實(shí)已經(jīng)失效，刪除該主鍵
sds key = dictGetKey(de);
robj *keyobj = createStringObject(key,sdslen(key));
同樣要在刪除前廣播該主鍵的失效信息
propagateExpire(db,keyobj);
dbDelete(db,keyobj);
decrRefCount(keyobj);
expired++;
server.stat_expiredkeys++;
}
}
每進(jìn)行一次抽樣刪除后對iteration加一，每16次抽樣刪除后檢查本次執(zhí)行時(shí)間是否
已經(jīng)達(dá)到時(shí)間限制，如果已達(dá)到時(shí)間限制，則記錄本次執(zhí)行達(dá)到時(shí)間限制并退出
iteration++;
if ((iteration & 0xf) == 0 &&
(ustime()-start) > timelimit)
{
timelimit_exit = 1;
return;
}
如果失效的主鍵數(shù)占抽樣數(shù)的百分比大于25%，則繼續(xù)抽樣刪除過程
} while (expired > REDIS_EXPIRELOOKUPS_PER_CRON/4);
}
}
三、Memcached刪除失效主鍵的方法與Redis有何異同？首先，Memcached在刪除失效主鍵時(shí)也是采用的消極方法，即Memcached內(nèi)部也不會(huì)監(jiān)視主鍵是否失效，而是在通過Get訪問主鍵時(shí)才會(huì)檢查其是否已經(jīng)失效。其次，Memcached與Redis在主鍵失效機(jī)制上的最大不同是，Memcached不會(huì)像Redis那樣真正地去刪除失效的主鍵，而只是簡單地將失效主鍵占用的空間回收。這樣當(dāng)有新的數(shù)據(jù)寫入到系統(tǒng)中時(shí)，Memcached會(huì)優(yōu)先使用那些失效主鍵的空間。如果失效主鍵的空間用光了，Memcached還可以通過LRU機(jī)制來回收那些長期得不到訪問的空間，因此Memcached并不需要像Redis中那樣的周期性刪除操作，這也是由Memcached使用的內(nèi)存管理機(jī)制決定的。同時(shí)，這里需要指出的是Redis在出現(xiàn)OOM時(shí)同樣可以通過配置maxmemory-policy這個(gè)參數(shù)來決定是否采用LRU機(jī)制來回收內(nèi)存空間（感謝@Jonathan_Dai同學(xué)在博文http://xenojoshua.com/2013/07/redis-lru/中對原文的指正[[114289]][[114289]][[114289]]）！
四、Redis的主鍵失效機(jī)制會(huì)不會(huì)影響系統(tǒng)性能？通過以上對Redis主鍵失效機(jī)制的介紹，我們知道雖然Redis會(huì)定期地檢查設(shè)置了失效時(shí)間的主鍵并刪除已經(jīng)失效的主鍵，但是通過對每次處理數(shù)據(jù)庫個(gè)數(shù)的限制、activeExpireCycle函數(shù)在一秒鐘內(nèi)執(zhí)行次數(shù)的限制、分配給activeExpireCycle函數(shù)CPU時(shí)間的限制、繼續(xù)刪除主鍵的失效主鍵數(shù)百分比的限制，Redis已經(jīng)大大降低了主鍵失效機(jī)制對系統(tǒng)整體性能的影響，但是如果在實(shí)際應(yīng)用中出現(xiàn)大量主鍵在短時(shí)間內(nèi)同時(shí)失效的情況還是會(huì)使得系統(tǒng)的響應(yīng)能力降低，所以這種情況無疑應(yīng)該避免。
參考文獻(xiàn)鏈接：http://redis.io/commands/expire & http://redis.io/topics/latency &
