溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

redis_memcached失效原理的示例分析

發(fā)布時(shí)間:2021-07-30 11:32:31 來源:億速云 閱讀:123 作者:小新 欄目:數(shù)據(jù)庫

這篇文章給大家分享的是有關(guān)redis_memcached失效原理的示例分析的內(nèi)容。小編覺得挺實(shí)用的,因此分享給大家做個(gè)參考,一起跟隨小編過來看看吧。

 一。如何才能觸發(fā)key的失效?

除了調(diào)用PERSIST命令外,還有沒有其他情況會(huì)撤銷一個(gè)主鍵的失效時(shí)間?答案是肯定的。

    1.在通過 DEL 命令刪除一個(gè)主鍵時(shí)
    2.在一個(gè)設(shè)置了失效時(shí)間的主鍵被更新覆蓋時(shí),該主鍵的失效時(shí)間也會(huì)被撤銷。
    3.特殊的命令就是 RENAME,當(dāng)我們使用 RENAME 對(duì)一個(gè)主鍵進(jìn)行重命名后,之前關(guān)聯(lián)的失效時(shí)間會(huì)自動(dòng)傳遞給新的主鍵,但是如果一個(gè)主鍵是被RENAME所覆蓋的話(如主鍵 hello 可能會(huì)被命令 RENAME world hello 所覆蓋),這時(shí)被覆蓋主鍵的失效時(shí)間會(huì)被自動(dòng)撤銷,而新的主鍵則繼續(xù)保持原來主鍵的特性。

注意,這里所說的是主鍵被更新覆蓋,而不是主鍵對(duì)應(yīng)的 Value 被更新覆蓋,因此 SET、MSET 或者是 GETSET 可能會(huì)導(dǎo)致主鍵被更新覆蓋,而像 INCR、DECR、LPUSH、HSET 等都是更新主鍵對(duì)應(yīng)的值,這類操作是不會(huì)觸碰主鍵的失效時(shí)間的。

二。Redis是如何管理和維護(hù)主鍵的

1).Redis的存儲(chǔ)結(jié)構(gòu)

typedef struct redisDb {
  dict *dict;//存儲(chǔ)主鍵和值的映射
  dict *expires;//存儲(chǔ)主鍵和過期時(shí)間的映射
  dict *blocking_keys;
  dict *ready_keys;
  dict *watched_keys;
  int id;
} redisDb;

主要看前兩個(gè)結(jié)構(gòu)就好,
dict:用來維護(hù)一個(gè) Redis 數(shù)據(jù)庫中包含的所有 Key-Value 對(duì)(其結(jié)構(gòu)可以理解為 dict[key]:value,即主鍵與值之間的映射)

expires:用于維護(hù)一個(gè) Redis 數(shù)據(jù)庫中設(shè)置了失效時(shí)間的主鍵(其結(jié)構(gòu)可以理解為 expires[key]:timeout,即主鍵與失效時(shí)間的映射)。

設(shè)置了失效時(shí)間的主鍵和具體的失效時(shí)間全部都維護(hù)在 expires 這個(gè)字典表中

當(dāng)我們使用 EXPIRE、EXPIREAT、PEXPIRE 和 PEXPIREAT 命令設(shè)置一個(gè)主鍵的失效時(shí)間時(shí),
Redis 首先到 dict 這個(gè)字典表中查找要設(shè)置的主鍵是否存在,如果存在就將這個(gè)主鍵和失效時(shí)間添加到 expires 這個(gè)字典表。

2).消極方法

1.expireIfNeeded函數(shù)

觸發(fā):這個(gè)函數(shù)在任何訪問數(shù)據(jù)的函數(shù)中都會(huì)被調(diào)用,Redis 在實(shí)現(xiàn) GET、MGET、HGET、LRANGE 等所有涉及到讀取數(shù)據(jù)的命令時(shí)都會(huì)調(diào)用它

意義:在讀取數(shù)據(jù)之前先檢查一下該key有沒有失效,如果失效了就刪除它。

2.propagateExpire函數(shù)(在上邊一個(gè)函數(shù)中調(diào)用) 主要函數(shù)

觸發(fā):執(zhí)行上一個(gè)函數(shù)時(shí),它在其里邊

意義:用來在正式刪除失效主鍵之前廣播這個(gè)主鍵已經(jīng)失效的信息

操作:
    (1).一個(gè)是發(fā)送到 AOF文件,將刪除失效主鍵的這一操作以 DEL Key 的標(biāo)準(zhǔn)命令格式記錄下來;
    (2).發(fā)送到當(dāng)前 Redis 服務(wù)器的所有 Slave,同樣將刪除失效主鍵的這一操作以 DEL Key 的標(biāo)準(zhǔn)命令格式告知這些 Slave 刪除各自的失效主鍵。

以上我們了解了 Redis 是如何以一種消極的方式刪除失效主鍵的,但是僅僅通過這種方式顯然是不夠的,因?yàn)槿绻承┦У闹麈I遲遲等不到再次訪問的話,Redis 就永遠(yuǎn)不會(huì)知道這些主鍵已經(jīng)失效,也就永遠(yuǎn)也不會(huì)刪除它們了,這無疑會(huì)導(dǎo)致內(nèi)存空間的浪費(fèi)。所以有了下邊的方法。

3).積極方法:(該方法利用 Redis 的時(shí)間事件來實(shí)現(xiàn),即每隔一段時(shí)間就中斷一下完成一些指定操作)

1.serverCron函數(shù):

觸發(fā):它在 Redis 服務(wù)器啟動(dòng)時(shí)創(chuàng)建

作用:這個(gè)回調(diào)函數(shù)不僅要進(jìn)行失效主鍵的檢查與刪除,還要進(jìn)行統(tǒng)計(jì)信息的更新、客戶端連接超時(shí)的控制、BGSAVE 和 AOF 的觸發(fā)等等

2.activeExpireCycle函數(shù):

觸發(fā):執(zhí)行上一個(gè)函數(shù)時(shí),它在其里邊每秒的執(zhí)行次數(shù)由宏定義 【REDIS_DEFAULT_HZ】 來指定,默認(rèn)每秒鐘執(zhí)行10次。

操作:
    a).遍歷處理 Redis 服務(wù)器中每個(gè)數(shù)據(jù)庫的 expires 字典表中,從中嘗試著隨機(jī)抽樣【REDIS_EXPIRELOOKUPS_PER_CRON】(默認(rèn) 值為10)個(gè)設(shè)置了失效時(shí)間的主鍵,
    b).檢查它們是否已經(jīng)失效并刪除掉失效的主鍵,
    c).如果失效的主鍵個(gè)數(shù)占本次抽樣個(gè)數(shù)的比例超過25%,Redis 會(huì)認(rèn)為當(dāng)前數(shù)據(jù)庫中的失效主鍵依然很多,所以它會(huì)繼續(xù)進(jìn)行下一輪的隨機(jī)抽樣和刪除,
    d).直到剛才的比例低于25%才停止對(duì)當(dāng)前數(shù)據(jù)庫的處理,轉(zhuǎn)向下一個(gè)數(shù)據(jù)庫。

其他:activeExpireCycle 函數(shù)避免失效主鍵刪除占用過多的CPU資源,所以其不會(huì)試圖一次性處理Redis中的所有數(shù)據(jù)庫,而是最多只處理 REDIS_DBCRON_DBS_PER_CALL(默認(rèn)值為16)個(gè)庫,有處理時(shí)間上的限制

三。Memcached 刪除失效主鍵的方法與 Redis 有何異同?

首先,Memcached 在刪除失效主鍵時(shí)也是采用的消極方法,即 Memcached 內(nèi)部也不會(huì)監(jiān)視主鍵是否失效,而是在通過 Get 訪問主鍵時(shí)才會(huì)檢查其是否已經(jīng)失效。

其次,Memcached 與 Redis 在主鍵失效機(jī)制上的最大不同是,Memcached 不會(huì)像 Redis 那樣真正地去刪除失效的主鍵,而只是簡(jiǎn)單地將失效主鍵占用的空間回收。這樣當(dāng)有新的數(shù)據(jù)寫入到系統(tǒng)中時(shí),Memcached 會(huì)優(yōu)先使用那些失效主鍵的空間。如果失效主鍵的空間用光了,Memcached 還可以通過 LRU 機(jī)制來回收那些長(zhǎng)期得不到訪問的空間,

因此 Memcached 并不需要像 Redis 中那樣的周期性刪除操作,這也是由 Memcached 使用的內(nèi)存管理機(jī)制決定的。同時(shí),這里需要指出的是 Redis 在出現(xiàn) OOM 時(shí)同樣可以通過配置 maxmemory-policy 這個(gè)參數(shù)來決定是否采用 LRU 機(jī)制來回收內(nèi)存空間 

四。總結(jié):

redis每秒執(zhí)行10次過期檢查,每次中,隨機(jī)從某個(gè)庫的expire表中抽取10個(gè)key,檢測(cè)他是否失效,若失效則刪除。當(dāng)失效比例超過1/4,本次重新執(zhí)行隨機(jī)抽取10key,不計(jì)入10次中的1次,直到這一秒的10次都執(zhí)行完。

問:

那么有人問了,萬一,萬一!失效的key做足夠的多,1秒的這10次都沒執(zhí)行完又到下一秒了,咋整?

答:

redis有檢測(cè)機(jī)制的,不會(huì)讓它把CPU拖死的:

a.每次處理數(shù)據(jù)庫個(gè)數(shù)的限制、

b.activeExpireCycle 函數(shù)在一秒鐘內(nèi)執(zhí)行次數(shù)的限制、

c.分配給 activeExpireCycle函數(shù)CPU時(shí)間的限制、

d.繼續(xù)刪除主鍵的失效主鍵數(shù)百分比的限制,Redis 已經(jīng)大大降低了主鍵失效機(jī)制對(duì)系統(tǒng)整體性能的影響,

所以由此也可得,設(shè)置失效時(shí)間的原則:盡可能避免在同一時(shí)間點(diǎn)的大批量key失效,它是需要處理時(shí)間的。

消極失效主要函數(shù).propagateExpire函數(shù):

void propagateExpire(redisDb *db, robj *key) {
  robj *argv[2];
  //shared.del是在Redis服務(wù)器啟動(dòng)之初就已經(jīng)初始化好的一個(gè)常用Redis對(duì)象,即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)樗?
  //只需聽從Master發(fā)送過來的命令就OK了
  if (listLength(server.slaves))
    replicationFeedSlaves(server.slaves,db->id,argv,2);
  decrRefCount(argv[0]);
  decrRefCount(argv[1]);
}

積極失效主要函數(shù).activeExpireCycle函數(shù):

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ù)的最長(zhǎng)時(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)行一次抽樣刪除后對(duì)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);
  }
}

感謝各位的閱讀!關(guān)于“redis_memcached失效原理的示例分析”這篇文章就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,讓大家可以學(xué)到更多知識(shí),如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到吧!

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI