Redis過期鍵刪除機制(主鍵失效)

作爲一種定期清理無效數據的重要機制,主鍵失效存在於大多數緩存系統中,Reids也不例外。在Redis提供的諸多命令中,EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT以及SETEX和PSETEX均可以用來設置一條Key-Value對的失效時間,而一條Key-Value對一旦被關聯了失效時間就會在到期後自動刪除(或者說變得無法訪問更爲準確)。可以說,主鍵失效這個概念還是比較容易理解的,但是在具體實現到Redis中又是如何呢?最近本博主就對Redis中的主鍵失效機制產生了幾個疑問,並根據這些疑問對其進行了仔細的探究,現總結所得如下,以饗各位看客。
  一、除了調用PERSIST命令外,還有沒有其他情況會撤銷一個主鍵的失效時間?答案是肯定的。首先,在通過DEL命令刪除一個主鍵時,失效時間自然會被撤銷(這不是廢話麼,哈哈)。其次,在一個設置了失效時間的主鍵被更新覆蓋時,該主鍵的失效時間也會被撤銷(這貌似也是廢話,哈哈)。但需要注意的是,這裏所說的是主鍵被更新覆蓋,而不是主鍵對應的Value被更新覆蓋,因此SET、MSET或者是GETSET可能會導致主鍵被更新覆蓋,而像INCR、DECR、LPUSH、HSET等都是更新主鍵對應的值,這類操作是不會觸碰主鍵的失效時間的。此外,還有一個特殊的命令就是RENAME,當我們使用RENAME對一個主鍵進行重命名後,之前關聯的失效時間會自動傳遞給新的主鍵,但是如果一個主鍵是被RENAME所覆蓋的話(如主鍵hello可能會被命令RENAMEworld hello所覆蓋),這時被覆蓋主鍵的失效時間會被自動撤銷,而新的主鍵則繼續保持原來主鍵的特性。
   二、Redis中的主鍵失效是如何實現的,即失效的主鍵是如何刪除的?實際上,Redis刪除失效主鍵的方法主要有兩種:1)消極方法(passiveway),在主鍵被訪問時如果發現它已經失效,那麼就刪除它;2)積極方法(activeway),週期性地從設置了失效時間的主鍵中選擇一部分失效的主鍵刪除。接下來我們就通過代碼來探究一下這兩種方法的具體實現,但在此之前,我們先看一看Redis是如何管理和維護主鍵的吧(注:本博文中的源碼全部來自Redis-2.6.12)。
   代碼段一給出了Redis中關於數據庫的結構體定義,這個結構體定義中除了id以外都是指向字典的指針,其中我們只看dict和expires,前者用來維護一個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這個字典表中。

代碼段一:

typedef struct redisDb {
   dict *dict;             
   dict *expires;            
    dict *blocking_keys;      
    dict *ready_keys;        
    dict *watched_keys;      
    int id;
} redisDb;

   在大致瞭解了Redis是如何維護設置了失效時間的主鍵之後,我們就先來看一看Redis是如何實現消極地刪除失效主鍵的。代碼段二給出了一個名爲expireIfNeeded的函數,這個函數在任何訪問數據的函數中都會被調用,也就是說Redis在實現GET、MGET、HGET、LRANGE等所有涉及到讀取數據的命令時都會調用它,它存在的意義就是在讀取數據之前先檢查一下它有沒有失效,如果失效了就刪除它。代碼段二中給出了expireIfNeeded函數的所有相關描述,這裏就不再重複它的實現方法了。這裏需要說明的是在expireIfNeeded函數中調用的另外一個函數propagateExpire,這個函數用來在正式刪除失效主鍵之前廣播這個主鍵已經失效的信息,這個信息會傳播到兩個目的地:一個是發送到AOF文件,將刪除失效主鍵的這一操作以DELKey的標準命令格式記錄下來;另一個就是發送到當前Redis服務器的所有Slave,同樣將刪除失效主鍵的這一操作以DELKey的標準命令格式告知這些Slave刪除各自的失效主鍵。從中我們可以知道,所有作爲Slave來運行的Redis服務器並不需要通過消極方法來刪除失效主鍵,它們只需要對Master唯命是從就OK了!
    
代碼段二: 
 
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);
    returndbDelete(db,key);
}

代碼段三:

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函數的介紹瞭解了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資源。代碼段五有對activeExpireCycle所有代碼的詳細描述,從中可以瞭解該函數的具體實現方法。

代碼段五:

void activeExpireCycle(void) {
   因爲每次調用activeExpireCycle函數不會一次性檢查所有Redis數據庫,所以需要記錄下
   每次函數調用處理的最後一個Redis數據庫的編號,這樣下次調用activeExpireCycle函數
   還可以從這個數據庫開始繼續處理,這就是current_db被聲明爲static的原因,而另外一
   個變量timelimit_exit是爲了記錄上一次調用activeExpireCycle函數的執行時間是否達
   到時間限制了,所以也需要聲明爲static
    static unsigned intcurrent_db = 0;
    static inttimelimit_exit = 0;     
    unsigned int j,iteration = 0;
   每次調用activeExpireCycle函數處理的Redis數據庫個數爲REDIS_DBCRON_DBS_PER_CALL
    unsigned intdbs_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/server.hz毫秒,
   乘以25%就是執行該函數一次所需要的時間,即
    (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 {
           unsignedlong num, slots;
           long longnow;
          如果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); 
    }
}
   三、Redis的主鍵失效機制會不會影響系統性能?通過以上對Redis主鍵失效機制的介紹,我們知道雖然Redis會定期地檢查設置了失效時間的主鍵並刪除已經失效的主鍵,但是通過對每次處理數據庫個數的限制、activeExpireCycle函數在一秒鐘內執行次數的限制、分配給activeExpireCycle函數CPU時間的限制、繼續刪除主鍵的失效主鍵數百分比的限制,Redis已經大大降低了主鍵失效機制對系統整體性能的影響,但是如果在實際應用中出現大量主鍵在短時間內同時失效的情況還是會使得系統的響應能力降低,所以這種情況無疑應該避免。

轉載出自於:http://blog.sina.com.cn/s/blog_48c95a190101e5hv.html
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章