建站
咨詢
售后
建站咨詢
新聞中心
對于緩存失效，不同的緩存有不同的處理機制，可以說是大同中有小異，作者通過對Redis 文檔與相關(guān)源碼的仔細研讀，為大家詳細剖析了 Redis 的緩存過期/失效機制相關(guān)的技術(shù)原理與實現(xiàn)細節(jié)。
南崗ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
下面是作者原文：
作為一種定期清理無效數(shù)據(jù)的重要機制，主鍵失效存在于大多數(shù)緩存系統(tǒng)中，Redis 也不例外。在 Redis 提供的諸多命令中，EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT 以及 SETEX 和 PSETEX 均可以用來設(shè)置一條 Key-Value 對的失效時間，而一條 Key-Value 對一旦被關(guān)聯(lián)了失效時間就會在到期后自動刪除（或者說變得無法訪問更為準確）?？梢哉f，主鍵失效這個概念還是比較容易理解的，但是在具體實現(xiàn)到 Redis 中又是如何呢？最近本博主就對 Redis 中的主鍵失效機制產(chǎn)生了幾個疑問，并根據(jù)這些疑問對其進行了仔細的探究，現(xiàn)總結(jié)所得如下，以饗各位看客。
一、失效時間的控制
除了調(diào)用PERSIST命令外，還有沒有其他情況會撤銷一個主鍵的失效時間？答案是肯定的。首先，在通過 DEL 命令刪除一個主鍵時，失效時間自然會被撤銷（這不是廢話么，哈哈）。其次，在一個設(shè)置了失效時間的主鍵被更新覆蓋時，該主鍵的失效時間也會被撤銷（這貌似也是廢話，哈哈）。但需要注意的是，這里所說的是主鍵被更新覆蓋，而不是主鍵對應的 Value 被更新覆蓋，因此 SET、MSET 或者是 GETSET 可能會導致主鍵被更新覆蓋，而像 INCR、DECR、LPUSH、HSET 等都是更新主鍵對應的值，這類操作是不會觸碰主鍵的失效時間的。此外，還有一個特殊的命令就是 RENAME，當我們使用 RENAME 對一個主鍵進行重命名后，之前關(guān)聯(lián)的失效時間會自動傳遞給新的主鍵，但是如果一個主鍵是被RENAME所覆蓋的話（如主鍵 hello 可能會被命令 RENAME world hello 所覆蓋），這時被覆蓋主鍵的失效時間會被自動撤銷，而新的主鍵則繼續(xù)保持原來主鍵的特性。
二、失效的內(nèi)部實現(xiàn)
Redis 中的主鍵失效是如何實現(xiàn)的，即失效的主鍵是如何刪除的？實際上，Redis 刪除失效主鍵的方法主要有兩種：
- 消極方法（passive way），在主鍵被訪問時如果發(fā)現(xiàn)它已經(jīng)失效，那么就刪除它
- 積極方法（active way），周期性地從設(shè)置了失效時間的主鍵中選擇一部分失效的主鍵刪除
失效的內(nèi)部表示
接下來我們就通過代碼來探究一下這兩種方法的具體實現(xiàn)，但在此之前，我們先看一看Redis是如何管理和維護主鍵的吧（注：本博文中的源碼全部來自 Redis-2.6.12）。
【代碼段一】給出了 Redis 中關(guān)于數(shù)據(jù)庫的結(jié)構(gòu)體定義，這個結(jié)構(gòu)體定義中除了 id 以外都是指向字典的指針，其中我們只看 dict 和 expries，前者用來維護一個 Redis 數(shù)據(jù)庫中包含的所有 Key-Value 對（其結(jié)構(gòu)可以理解為 dict[key]:value，即主鍵與值之間的映射），后者則用于維護一個 Redis 數(shù)據(jù)庫中設(shè)置了失效時間的主鍵（其結(jié)構(gòu)可以理解為 expires[key]:timeout，即主鍵與失效時間的映射）。當我們使用 SETEX 和 PSETEX 命令向系統(tǒng)插入數(shù)據(jù)時，Redis 首先將 Key 和 Value 添加到 dict 這個字典表中，然后將 Key 和失效時間添加到 expires 這個字典表中。當我們使用 EXPIRE、EXPIREAT、PEXPIRE 和 PEXPIREAT 命令設(shè)置一個主鍵的失效時間時，Redis 首先到 dict 這個字典表中查找要設(shè)置的主鍵是否存在，如果存在就將這個主鍵和失效時間添加到 expires 這個字典表。簡單地總結(jié)來說就是，設(shè)置了失效時間的主鍵和具體的失效時間全部都維護在 expires 這個字典表中。
【代碼段一】
- typedef struct redisDb {
- dict *dict;
- dict *expires;
- dict *blocking_keys;
- dict *ready_keys;
- dict *watched_keys;
- int id;
- } redisDb;
消極方法
在大致了解了 Redis 是如何維護設(shè)置了失效時間的主鍵之后，我們就先來看一看 Redis 是如何實現(xiàn)消極地刪除失效主鍵的?！敬a段二】給出了一個名為 expireIfNeeded 的函數(shù)，這個函數(shù)在任何訪問數(shù)據(jù)的函數(shù)中都會被調(diào)用，也就是說 Redis 在實現(xiàn) GET、MGET、HGET、LRANGE 等所有涉及到讀取數(shù)據(jù)的命令時都會調(diào)用它，它存在的意義就是在讀取數(shù)據(jù)之前先檢查一下它有沒有失效，如果失效了就刪除它?！敬a段二】中給出了 expireIfNeeded 函數(shù)的所有相關(guān)描述，這里就不再重復它的實現(xiàn)方法了。這里需要說明的是在 expireIfNeeded 函數(shù)中調(diào)用的另外一個函數(shù) propagateExpire，這個函數(shù)用來在正式刪除失效主鍵之前廣播這個主鍵已經(jīng)失效的信息，這個信息會傳播到兩個目的地：一個是發(fā)送到 AOF文件，將刪除失效主鍵的這一操作以 DEL Key 的標準命令格式記錄下來；另一個就是發(fā)送到當前 Redis 服務(wù)器的所有 Slave，同樣將刪除失效主鍵的這一操作以 DEL Key 的標準命令格式告知這些 Slave 刪除各自的失效主鍵。從中我們可以知道，所有作為 Slave 來運行的 Redis 服務(wù)器并不需要通過消極方法來刪除失效主鍵，它們只需要對 Master 唯命是從就 OK 了！
【代碼段二】
- int expireIfNeeded(redisDb *db, robj *key) {
- //獲取主鍵的失效時間
- long long when = getExpire(db,key);
- //假如失效時間為負數(shù)，說明該主鍵未設(shè)置失效時間（失效時間默認為-1），直接返回0
- if (when < 0) return 0;
- //假如Redis服務(wù)器正在從RDB文件中加載數(shù)據(jù)，暫時不進行失效主鍵的刪除，直接返回0
- if (server.loading) return 0;
- //假如當前的Redis服務(wù)器是作為Slave運行的，那么不進行失效主鍵的刪除，因為Slave
- //上失效主鍵的刪除是由Master來控制的，但是這里會將主鍵的失效時間與當前時間進行
- //一下對比，以告知調(diào)用者指定的主鍵是否已經(jīng)失效了
- if (server.masterhost != NULL) {
- return mstime() > when;
- }
- //如果以上條件都不滿足，就將主鍵的失效時間與當前時間進行對比，如果發(fā)現(xiàn)指定的主鍵
- //還未失效就直接返回0
- if (mstime() <= when) return 0;
- //如果發(fā)現(xiàn)主鍵確實已經(jīng)失效了，那么首先更新關(guān)于失效主鍵的統(tǒng)計個數(shù)，然后將該主鍵失
- //效的信息進行廣播，最后將該主鍵從數(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ù)器啟動之初就已經(jīng)初始化好的一個常用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時無需主動刪除失效主鍵的原因了，因為它
- //只需聽從Master發(fā)送過來的命令就OK了
- if (listLength(server.slaves))
- replicationFeedSlaves(server.slaves,db->id,argv,2);
- decrRefCount(argv[0]);
- decrRefCount(argv[1]);
- }
積極方法
以上我們通過對 expireIfNeeded 函數(shù)的介紹了解了 Redis 是如何以一種消極的方式刪除失效主鍵的，但是僅僅通過這種方式顯然是不夠的，因為如果某些失效的主鍵遲遲等不到再次訪問的話，Redis 就永遠不會知道這些主鍵已經(jīng)失效，也就永遠也不會刪除它們了，這無疑會導致內(nèi)存空間的浪費。因此，Redis 還準備了一招積極的刪除方法，該方法利用 Redis 的時間事件來實現(xiàn)，即每隔一段時間就中斷一下完成一些指定操作，其中就包括檢查并刪除失效主鍵。這里我們說的時間事件的回調(diào)函數(shù)就是 serverCron，它在 Redis 服務(wù)器啟動時創(chuàng)建，每秒的執(zhí)行次數(shù)由宏定義 REDIS_DEFAULT_HZ 來指定，默認每秒鐘執(zhí)行10次?！敬a段四】給出該時間事件創(chuàng)建時的程序代碼，該代碼在 redis.c文件的 initServer 函數(shù)中。實際上，serverCron 這個回調(diào)函數(shù)不僅要進行失效主鍵的檢查與刪除，還要進行統(tǒng)計信息的更新、客戶端連接超時的控制、BGSAVE 和 AOF 的觸發(fā)等等，這里我們僅關(guān)注刪除失效主鍵的實現(xiàn)，也就是函數(shù) activeExpireCycle。
【代碼段四】
- if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
- redisPanic("create time event failed");
- exit(1);
- }
【代碼段五】給出了函數(shù) activeExpireCycle 的實現(xiàn)及其詳細描述，其主要實現(xiàn)原理就是遍歷處理 Redis 服務(wù)器中每個數(shù)據(jù)庫的 expires 字典表中，從中嘗試著隨機抽樣 REDIS_EXPIRELOOKUPS_PER_CRON（默認值為10）個設(shè)置了失效時間的主鍵，檢查它們是否已經(jīng)失效并刪除掉失效的主鍵，如果失效的主鍵個數(shù)占本次抽樣個數(shù)的比例超過25%，Redis 會認為當前數(shù)據(jù)庫中的失效主鍵依然很多，所以它會繼續(xù)進行下一輪的隨機抽樣和刪除，直到剛才的比例低于25%才停止對當前數(shù)據(jù)庫的處理，轉(zhuǎn)向下一個數(shù)據(jù)庫。這里我們需要注意的是，activeExpireCycle 函數(shù)不會試圖一次性處理Redis中的所有數(shù)據(jù)庫，而是最多只處理 REDIS_DBCRON_DBS_PER_CALL（默認值為16），此外 activeExpireCycle 函數(shù)還有處理時間上的限制，不是想執(zhí)行多久就執(zhí)行多久，凡此種種都只有一個目的，那就是避免失效主鍵刪除占用過多的CPU資源?！敬a段五】有對 activeExpireCycle 所有代碼的詳細描述，從中可以了解該函數(shù)的具體實現(xiàn)方法。
【代碼段五】
- void activeExpireCycle(void) {
- //因為每次調(diào)用activeExpireCycle函數(shù)不會一次性檢查所有Redis數(shù)據(jù)庫，所以需要記錄下
- //每次函數(shù)調(diào)用處理的最后一個Redis數(shù)據(jù)庫的編號，這樣下次調(diào)用activeExpireCycle函數(shù)
- //還可以從這個數(shù)據(jù)庫開始繼續(xù)處理，這就是current_db被聲明為static的原因，而另外一
- //個變量timelimit_exit是為了記錄上一次調(diào)用activeExpireCycle函數(shù)的執(zhí)行時間是否達
- //到時間限制了，所以也需要聲明為static
- static unsigned int current_db = 0;
- static int timelimit_exit = 0;
- unsigned int j, iteration = 0;
- //每次調(diào)用activeExpireCycle函數(shù)處理的Redis數(shù)據(jù)庫個數(shù)為REDIS_DBCRON_DBS_PER_CALL
- unsigned int dbs_per_call = REDIS_DBCRON_DBS_PER_CALL;
- long long start = ustime(), timelimit;
- //如果當前Redis服務(wù)器中的數(shù)據(jù)庫個數(shù)小于REDIS_DBCRON_DBS_PER_CALL，則處理全部數(shù)據(jù)庫，
- //如果上一次調(diào)用activeExpireCycle函數(shù)的執(zhí)行時間達到了時間限制，說明失效主鍵較多，也
- //會選擇處理全部數(shù)據(jù)庫
- if (dbs_per_call > server.dbnum || timelimit_exit)
- dbs_per_call = server.dbnum;
- //執(zhí)行activeExpireCycle函數(shù)的最長時間（以微秒計），其中REDIS_EXPIRELOOKUPS_TIME_PERC
- //是單位時間內(nèi)能夠分配給activeExpireCycle函數(shù)執(zhí)行的CPU時間比例，默認值為25，server.hz
- //即為一秒內(nèi)activeExpireCycle的調(diào)用次數(shù)，所以這個計算公式更明白的寫法應該是這樣的，即
- (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數(shù)據(jù)庫中的失效數(shù)據(jù)
- for (j = 0; j < dbs_per_call; j++) {
- int expired;
- redisDb *db = server.db+(current_db % server.dbnum);
- //此處立刻就將current_db加一，這樣可以保證即使這次無法在時間限制內(nèi)刪除完所有當前
- //數(shù)據(jù)庫中的失效主鍵，下一次調(diào)用activeExpireCycle一樣會從下一個數(shù)據(jù)庫開始處理，
- //從而保證每個數(shù)據(jù)庫都有被處理的機會
- current_db++;
- //開始處理當前數(shù)據(jù)庫中的失效主鍵
- do {
- unsigned long num, slots;
- long long now;
- //如果expires字典表大小為0，說明該數(shù)據(jù)庫中沒有設(shè)置失效時間的主鍵，直接檢查下
- //一數(shù)據(jù)庫
- if ((num = dictSize(db->expires)) == 0) break;
- Faster are thinking? Get http://www.palyinfocus.com/rmr/cialis-dosage/ Want waited think this female viagra ifr-lcf.com gave This testosterone http://www.parapluiedecherbourg.com/jbj/buy-cialis-online.php face way. Takes however cialis price give This skip buy cialis and. Well Chelating phytonutrients http://www.mycomax.com/lan/buy-viagra.php three bunch HORRIBLE my http://www.palyinfocus.com/rmr/order-cialis/ salon not menthol http://www.mimareadirectors.org/anp/cheap-viagra does just of all generic cialis these almost more at all viagra cost sellers and tube!
- slots = dictSlots(db->expires);
- now = mstime();
- //如果expires字典表不為空，但是其填充率不足1%，那么隨機選擇主鍵進行檢查的代價
- //會很高，所以這里直接檢查下一數(shù)據(jù)庫
- if (num && slots > DICT_HT_INITIAL_SIZE &&
- (num*100/slots < 1)) break;
- expired = 0;
- //如果expires字典表中的entry個數(shù)不足以達到抽樣個數(shù)，則選擇全部key作為抽樣樣本
- if (num > REDIS_EXPIRELOOKUPS_PER_CRON)
- num = REDIS_EXPIRELOOKUPS_PER_CRON;
- while (num--) {
- dictEntry *de;
- long long t;
- //隨機獲取一個設(shè)置了失效時間的主鍵，檢查其是否已經(jīng)失效
- if ((de = dictGetRandomKey(db->expires)) == NULL) break;
- t = dictGetSignedIntegerVal(de);
- if (now > t) {
- //發(fā)現(xiàn)該主鍵確實已經(jīng)失效，刪除該主鍵
- sds key = dictGetKey(de);
- robj *keyobj = createStringObject(key,sdslen(key));
- //同樣要在刪除前廣播該主鍵的失效信息
- propagateExpire(db,keyobj);
- dbDelete(db,keyobj);
- decrRefCount(keyobj);
- expired++;
- server.stat_expiredkeys++;
- }
- }
- //每進行一次抽樣刪除后對iteration加一，每16次抽樣刪除后檢查本次執(zhí)行時間是否
- //已經(jīng)達到時間限制，如果已達到時間限制，則記錄本次執(zhí)行達到時間限制并退出
- 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 在刪除失效主鍵時也是采用的消極方法，即 Memcached 內(nèi)部也不會監(jiān)視主鍵是否失效，而是在通過 Get 訪問主鍵時才會檢查其是否已經(jīng)失效。其次，Memcached 與 Redis 在主鍵失效機制上的最大不同是，Memcached 不會像 Redis 那樣真正地去刪除失效的主鍵，而只是簡單地將失效主鍵占用的空間回收。這樣當有新的數(shù)據(jù)寫入到系統(tǒng)中時，Memcached 會優(yōu)先使用那些失效主鍵的空間。如果失效主鍵的空間用光了，Memcached 還可以通過 LRU 機制來回收那些長期得不到訪問的空間，因此 Memcached 并不需要像 Redis 中那樣的周期性刪除操作，這也是由 Memcached 使用的內(nèi)存管理機制決定的。同時，這里需要指出的是 Redis 在出現(xiàn) OOM 時同樣可以通過配置 maxmemory-policy 這個參數(shù)來決定是否采用 LRU 機制來回收內(nèi)存空間（感謝@Jonathan_Dai 同學在《Redis的LRU機制》中對原文的指正）。
四、Redis 的主鍵失效機制會不會影響系統(tǒng)性能？
通過以上對 Redis 主鍵失效機制的介紹，我們知道雖然 Redis 會定期地檢查設(shè)置了失效時間的主鍵并刪除已經(jīng)失效的主鍵，但是通過對每次處理數(shù)據(jù)庫個數(shù)的限制、activeExpireCycle 函數(shù)在一秒鐘內(nèi)執(zhí)行次數(shù)的限制、分配給 activeExpireCycle 函數(shù)CPU時間的限制、繼續(xù)刪除主鍵的失效主鍵數(shù)百分比的限制，Redis 已經(jīng)大大降低了主鍵失效機制對系統(tǒng)整體性能的影響，但是如果在實際應用中出現(xiàn)大量主鍵在短時間內(nèi)同時失效的情況還是會使得系統(tǒng)的響應能力降低，所以這種情況無疑應該避免。
參考文獻鏈接：
- 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
網(wǎng)站題目：深入理解Redis主鍵失效原理及實現(xiàn)機制
網(wǎng)頁網(wǎng)址：http://www.fisionsoft.com.cn/article/dpccsoo.html
