深入理解Redis中的主鍵失效及其實現機制

五柳-先生發表於2016-06-06
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可能會被命令RENAME world hello所覆蓋），這時被覆蓋主鍵的失效時間會被自動撤銷，而新的主鍵則繼續保持原來主鍵的特性。
    二、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); 
    }
}
    三、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/中對原文的指正深入理解Redis中的主鍵失效及其實現機制深入理解Redis中的主鍵失效及其實現機制深入理解Redis中的主鍵失效及其實現機制）！
 四、Redis的主鍵失效機制會不會影響系統效能？通過以上對Redis主鍵失效機制的介紹，我們知道雖然Redis會定期地檢查設定了失效時間的主鍵並刪除已經失效的主鍵，但是通過對每次處理資料庫個數的限制、activeExpireCycle函式在一秒鐘內執行次數的限制、分配給activeExpireCycle函式CPU時間的限制、繼續刪除主鍵的失效主鍵數百分比的限制，Redis已經大大降低了主鍵失效機制對系統整體效能的影響，但是如果在實際應用中出現大量主鍵在短時間內同時失效的情況還是會使得系統的響應能力降低，所以這種情況無疑應該避免。

相關文章