深刻理解Redis主鍵失效原理及實現機制

      做爲一種按期清理無效數據的重要機制，主鍵失效存在於大多數緩存系統中，Reids也不例外。在Redis提供的諸多命令中， EXPIRE、 EXPIREAT、 PEXPIRE、 PEXPIREAT以及SETEX和PSETEX都可以用來設置一條Key-Value對的失效時間，而一條Key-Value對一旦被關聯了失效時間就會在到期後自動刪除（或者說變得沒法訪問更爲準確）。能夠說，主鍵失效這個概念仍是比較容易理解的，可是在具體實現到Redis中又是如何呢？最近本博主就對Redis中的主鍵失效機制產生了幾個疑問，並根據這些疑問對其進行了仔細的探究，現總結所得以下，以饗各位看客。

    1、除了調用PERSIST命令外，還有沒有其餘狀況會撤銷一個主鍵的失效時間？答案是確定的。首先，在經過DEL命令刪除一個主鍵時，失效時間天然會被撤銷（這不是廢話麼，哈哈）。其次，在一個設置了失效時間的主鍵被更新覆蓋時，該主鍵的失效時間也會被撤銷（這貌似也是廢話，哈哈）。但須要注意的是，這裏所說的是主鍵被更新覆蓋，而不是主鍵對應的Value被更新覆蓋，所以SET、MSET或者是GETSET可能會致使主鍵被更新覆蓋，而像INCR、DECR、LPUSH、HSET等都是更新主鍵對應的值，這類操做是不會觸碰主鍵的失效時間的。此外，還有一個特殊的命令就是RENAME，當咱們使用RENAME對一個主鍵進行重命名後，以前關聯的失效時間會自動傳遞給新的主鍵，可是若是一個主鍵是被RENAME所覆蓋的話（如主鍵hello可能會被命令RENAME world hello所覆蓋），這時被覆蓋主鍵的失效時間會被自動撤銷，而新的主鍵則繼續保持原來主鍵的特性。

    2、Redis中的主鍵失效是如何實現的，即失效的主鍵是如何刪除的？實際上，Redis刪除失效主鍵的方法主要有兩種：1）消極方法（passive way），在主鍵被訪問時若是發現它已經失效，那麼就刪除它；2）積極方法（active way），週期性地從設置了失效時間的主鍵中選擇一部分失效的主鍵刪除。接下來咱們就經過代碼來探究一下這兩種方法的具體實現，但在此以前，咱們先看一看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文件，將刪除失效主鍵的這一操做以DEL Key的標準命令格式記錄下來；另外一個就是發送到當前Redis服務器的全部Slave，一樣將刪除失效主鍵的這一操做以DEL Key的標準命令格式告知這些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);

    return dbDelete(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 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); 

    }

}

    3、Memcached刪除失效主鍵的方法與Redis有何異同？首先，Memcached在刪除失效主鍵時也是採用的消極方法，即Memcached內部也不會監視主鍵是否失效，而是在經過Get訪問主鍵時纔會檢查其是否已經失效。其次，Memcached與Redis在主鍵失效機制上的最大不一樣是，Memcached不會像Redis那樣真正地去刪除失效的主鍵，而只是簡單地將失效主鍵佔用的空間回收。這樣當有新的數據寫入到系統中時，Memcached會優先使用那些失效主鍵的空間。若是失效主鍵的空間用光了，Memcached還能夠經過LRU機制來回收那些長期得不到訪問的空間，所以Memcached並不須要像Redis中那樣的週期性刪除操做，這也是由Memcached使用的內存管理機制決定的。同時，這裏須要指出的是Redis在出現OOM時一樣能夠經過配置maxmemory-policy這個參數來決定是否採用LRU機制來回收內存空間（感謝@Jonathan_Dai同窗在博文 http://xenojoshua.com/2013/07/redis-lru/中對原文的指正 ）！

    4、Redis的主鍵失效機制會不會影響系統性能？經過以上對Redis主鍵失效機制的介紹，咱們知道雖然Redis會按期地檢查設置了失效時間的主鍵並刪除已經失效的主鍵，可是經過對每次處理數據庫個數的限制、activeExpireCycle函數在一秒鐘內執行次數的限制、分配給activeExpireCycle函數CPU時間的限制、繼續刪除主鍵的失效主鍵數百分比的限制，Redis已經大大下降了主鍵失效機制對系統總體性能的影響，可是若是在實際應用中出現大量主鍵在短期內同時失效的狀況仍是會使得系統的響應能力下降，因此這種狀況無疑應該避免。

參考文獻連接： http://redis.io/commands/expire &  http://redis.io/topics/latency &

http://www.cppblog.com/richbirdandy/archive/2011/11/29/161184.html &

http://www.cnblogs.com/tangtianfly/archive/2012/05/02/2479315.html