欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Redis中LFU算法的深入分析

 更新時(shí)間:2019年06月02日 11:50:01   作者:再見紫羅蘭  
這篇文章主要給大家介紹了關(guān)于Redis中LFU算法的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用Redis具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧

前言

Redis中的LRU算法文中說到,LRU有一個(gè)缺陷,在如下情況下:

~~~~~A~~~~~A~~~~~A~~~~A~~~~~A~~~~~A~~|
~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~|
~~~~~~~~~~C~~~~~~~~~C~~~~~~~~~C~~~~~~|
~~~~~D~~~~~~~~~~D~~~~~~~~~D~~~~~~~~~D|

會(huì)將數(shù)據(jù)D誤認(rèn)為將來最有可能被訪問到的數(shù)據(jù)。

Redis作者曾想改進(jìn)LRU算法,但發(fā)現(xiàn)Redis的LRU算法受制于隨機(jī)采樣數(shù)maxmemory_samples,在maxmemory_samples等于10的情況下已經(jīng)很接近于理想的LRU算法性能,也就是說,LRU算法本身已經(jīng)很難再進(jìn)一步了。

于是,將思路回到原點(diǎn),淘汰算法的本意是保留那些將來最有可能被再次訪問的數(shù)據(jù),而LRU算法只是預(yù)測最近被訪問的數(shù)據(jù)將來最有可能被訪問到。我們可以轉(zhuǎn)變思路,采用一種LFU(Least Frequently Used)算法,也就是最頻繁被訪問的數(shù)據(jù)將來最有可能被訪問到。在上面的情況中,根據(jù)訪問頻繁情況,可以確定保留優(yōu)先級(jí):B>A>C=D。

Redis中的LFU思路

在LFU算法中,可以為每個(gè)key維護(hù)一個(gè)計(jì)數(shù)器。每次key被訪問的時(shí)候,計(jì)數(shù)器增大。計(jì)數(shù)器越大,可以約等于訪問越頻繁。

上述簡單算法存在兩個(gè)問題:

  • 在LRU算法中可以維護(hù)一個(gè)雙向鏈表,然后簡單的把被訪問的節(jié)點(diǎn)移至鏈表開頭,但在LFU中是不可行的,節(jié)點(diǎn)要嚴(yán)格按照計(jì)數(shù)器進(jìn)行排序,新增節(jié)點(diǎn)或者更新節(jié)點(diǎn)位置時(shí),時(shí)間復(fù)雜度可能達(dá)到O(N)。
  • 只是簡單的增加計(jì)數(shù)器的方法并不完美。訪問模式是會(huì)頻繁變化的,一段時(shí)間內(nèi)頻繁訪問的key一段時(shí)間之后可能會(huì)很少被訪問到,只增加計(jì)數(shù)器并不能體現(xiàn)這種趨勢。

第一個(gè)問題很好解決,可以借鑒LRU實(shí)現(xiàn)的經(jīng)驗(yàn),維護(hù)一個(gè)待淘汰key的pool。第二個(gè)問題的解決辦法是,記錄key最后一個(gè)被訪問的時(shí)間,然后隨著時(shí)間推移,降低計(jì)數(shù)器。

Redis對(duì)象的結(jié)構(gòu)如下:

typedef struct redisObject {
  unsigned type:4;
  unsigned encoding:4;
  unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
              * LFU data (least significant 8 bits frequency
              * and most significant 16 bits access time). */
  int refcount;
  void *ptr;
} robj;

在LRU算法中,24 bits的lru是用來記錄LRU time的,在LFU中也可以使用這個(gè)字段,不過是分成16 bits與8 bits使用:

      16 bits   8 bits
   +----------------+--------+
   + Last decr time | LOG_C |
   +----------------+--------+

高16 bits用來記錄最近一次計(jì)數(shù)器降低的時(shí)間ldt,單位是分鐘,低8 bits記錄計(jì)數(shù)器數(shù)值counter。

LFU配置

Redis4.0之后為maxmemory_policy淘汰策略添加了兩個(gè)LFU模式:

  • volatile-lfu:對(duì)有過期時(shí)間的key采用LFU淘汰算法
  • allkeys-lfu:對(duì)全部key采用LFU淘汰算法

還有2個(gè)配置可以調(diào)整LFU算法:

lfu-log-factor 10
lfu-decay-time 1

lfu-log-factor可以調(diào)整計(jì)數(shù)器counter的增長速度,lfu-log-factor越大,counter增長的越慢。

lfu-decay-time是一個(gè)以分鐘為單位的數(shù)值,可以調(diào)整counter的減少速度

源碼實(shí)現(xiàn)

在lookupKey中:

robj *lookupKey(redisDb *db, robj *key, int flags) {
  dictEntry *de = dictFind(db->dict,key->ptr);
  if (de) {
    robj *val = dictGetVal(de);

    /* Update the access time for the ageing algorithm.
     * Don't do it if we have a saving child, as this will trigger
     * a copy on write madness. */
    if (server.rdb_child_pid == -1 &&
      server.aof_child_pid == -1 &&
      !(flags & LOOKUP_NOTOUCH))
    {
      if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {
        updateLFU(val);
      } else {
        val->lru = LRU_CLOCK();
      }
    }
    return val;
  } else {
    return NULL;
  }
}

當(dāng)采用LFU策略時(shí),updateLFU更新lru:

/* Update LFU when an object is accessed.
 * Firstly, decrement the counter if the decrement time is reached.
 * Then logarithmically increment the counter, and update the access time. */
void updateLFU(robj *val) {
  unsigned long counter = LFUDecrAndReturn(val);
  counter = LFULogIncr(counter);
  val->lru = (LFUGetTimeInMinutes()<<8) | counter;
}

降低LFUDecrAndReturn

首先,LFUDecrAndReturn對(duì)counter進(jìn)行減少操作:

/* If the object decrement time is reached decrement the LFU counter but
 * do not update LFU fields of the object, we update the access time
 * and counter in an explicit way when the object is really accessed.
 * And we will times halve the counter according to the times of
 * elapsed time than server.lfu_decay_time.
 * Return the object frequency counter.
 *
 * This function is used in order to scan the dataset for the best object
 * to fit: as we check for the candidate, we incrementally decrement the
 * counter of the scanned objects if needed. */
unsigned long LFUDecrAndReturn(robj *o) {
  unsigned long ldt = o->lru >> 8;
  unsigned long counter = o->lru & 255;
  unsigned long num_periods = server.lfu_decay_time ? LFUTimeElapsed(ldt) / server.lfu_decay_time : 0;
  if (num_periods)
    counter = (num_periods > counter) ? 0 : counter - num_periods;
  return counter;
}

函數(shù)首先取得高16 bits的最近降低時(shí)間ldt與低8 bits的計(jì)數(shù)器counter,然后根據(jù)配置的lfu_decay_time計(jì)算應(yīng)該降低多少。

LFUTimeElapsed用來計(jì)算當(dāng)前時(shí)間與ldt的差值:

/* Return the current time in minutes, just taking the least significant
 * 16 bits. The returned time is suitable to be stored as LDT (last decrement
 * time) for the LFU implementation. */
unsigned long LFUGetTimeInMinutes(void) {
  return (server.unixtime/60) & 65535;
}

/* Given an object last access time, compute the minimum number of minutes
 * that elapsed since the last access. Handle overflow (ldt greater than
 * the current 16 bits minutes time) considering the time as wrapping
 * exactly once. */
unsigned long LFUTimeElapsed(unsigned long ldt) {
  unsigned long now = LFUGetTimeInMinutes();
  if (now >= ldt) return now-ldt;
  return 65535-ldt+now;
}

具體是當(dāng)前時(shí)間轉(zhuǎn)化成分鐘數(shù)后取低16 bits,然后計(jì)算與ldt的差值now-ldt。當(dāng)ldt > now時(shí),默認(rèn)為過了一個(gè)周期(16 bits,最大65535),取值65535-ldt+now。

然后用差值與配置lfu_decay_time相除,LFUTimeElapsed(ldt) / server.lfu_decay_time,已過去n個(gè)lfu_decay_time,則將counter減少n,counter - num_periods。

增長LFULogIncr

增長函數(shù)LFULogIncr如下:

/* Logarithmically increment a counter. The greater is the current counter value
 * the less likely is that it gets really implemented. Saturate it at 255. */
uint8_t LFULogIncr(uint8_t counter) {
  if (counter == 255) return 255;
  double r = (double)rand()/RAND_MAX;
  double baseval = counter - LFU_INIT_VAL;
  if (baseval < 0) baseval = 0;
  double p = 1.0/(baseval*server.lfu_log_factor+1);
  if (r < p) counter++;
  return counter;
}

counter并不是簡單的訪問一次就+1,而是采用了一個(gè)0-1之間的p因子控制增長。counter最大值為255。取一個(gè)0-1之間的隨機(jī)數(shù)r與p比較,當(dāng)r<p時(shí),才增加counter,這和比特幣中控制產(chǎn)出的策略類似。p取決于當(dāng)前counter值與lfu_log_factor因子,counter值與lfu_log_factor因子越大,p越小,r<p的概率也越小,counter增長的概率也就越小。增長情況如下:

+--------+------------+------------+------------+------------+------------+
| factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |
+--------+------------+------------+------------+------------+------------+
| 0      | 104        | 255        | 255        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 1      | 18         | 49         | 255        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 10     | 10         | 18         | 142        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 100    | 8          | 11         | 49         | 143        | 255        |
+--------+------------+------------+------------+------------+------------+

可見counter增長與訪問次數(shù)呈現(xiàn)對(duì)數(shù)增長的趨勢,隨著訪問次數(shù)越來越大,counter增長的越來越慢。

新生key策略

另外一個(gè)問題是,當(dāng)創(chuàng)建新對(duì)象的時(shí)候,對(duì)象的counter如果為0,很容易就會(huì)被淘汰掉,還需要為新生key設(shè)置一個(gè)初始counter,createObject:

robj *createObject(int type, void *ptr) {
  robj *o = zmalloc(sizeof(*o));
  o->type = type;
  o->encoding = OBJ_ENCODING_RAW;
  o->ptr = ptr;
  o->refcount = 1;

  /* Set the LRU to the current lruclock (minutes resolution), or
   * alternatively the LFU counter. */
  if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {
    o->lru = (LFUGetTimeInMinutes()<<8) | LFU_INIT_VAL;
  } else {
    o->lru = LRU_CLOCK();
  }
  return o;
}

counter會(huì)被初始化為LFU_INIT_VAL,默認(rèn)5。

pool

pool算法就與LRU算法一致了:

    if (server.maxmemory_policy & (MAXMEMORY_FLAG_LRU|MAXMEMORY_FLAG_LFU) ||
      server.maxmemory_policy == MAXMEMORY_VOLATILE_TTL)

計(jì)算idle時(shí)有所不同:

    } else if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {
      /* When we use an LRU policy, we sort the keys by idle time
       * so that we expire keys starting from greater idle time.
       * However when the policy is an LFU one, we have a frequency
       * estimation, and we want to evict keys with lower frequency
       * first. So inside the pool we put objects using the inverted
       * frequency subtracting the actual frequency to the maximum
       * frequency of 255. */
      idle = 255-LFUDecrAndReturn(o);

使用了255-LFUDecrAndReturn(o)當(dāng)做排序的依據(jù)。

參考鏈接

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。

相關(guān)文章

  • Redis官方ORM框架比RedisTemplate更優(yōu)雅

    Redis官方ORM框架比RedisTemplate更優(yōu)雅

    這篇文章主要為大家介紹了Redis官方ORM框架比RedisTemplate更優(yōu)雅的使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-07-07
  • redis啟動(dòng)報(bào)錯(cuò)Can‘t?open?the?log?file:?No?such?file?or?directory

    redis啟動(dòng)報(bào)錯(cuò)Can‘t?open?the?log?file:?No?such?file?or?d

    這篇文章主要介紹了redis啟動(dòng)報(bào)錯(cuò)Can‘t?open?the?log?file:?No?such?file?or?directory問題及解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2023-11-11
  • Redis內(nèi)部數(shù)據(jù)結(jié)構(gòu)Dict的實(shí)現(xiàn)方法

    Redis內(nèi)部數(shù)據(jù)結(jié)構(gòu)Dict的實(shí)現(xiàn)方法

    這篇文章主要介紹了Redis內(nèi)部數(shù)據(jù)結(jié)構(gòu)Dict的實(shí)現(xiàn)方法,本篇文章所述的dict在Redis中最主要的作用就是用于維護(hù)Redis數(shù)據(jù)庫中所有Key、value映射的數(shù)據(jù)結(jié)構(gòu),需要的朋友可以參考下
    2022-05-05
  • Redis教程(十四):內(nèi)存優(yōu)化介紹

    Redis教程(十四):內(nèi)存優(yōu)化介紹

    這篇文章主要介紹了Redis教程(十四):內(nèi)存優(yōu)化介紹,本文講解了特殊編碼、BIT和Byte級(jí)別的操作、盡可能使用Hash等內(nèi)容,需要的朋友可以參考下
    2015-05-05
  • 聊聊redis-dump工具安裝問題

    聊聊redis-dump工具安裝問題

    這篇文章主要介紹了redis-dump工具安裝問題,由于安裝redis-dump工具需要使用rvm?和gem工具所以要提前安裝,詳細(xì)的安裝過程本文給大家提到過,需要的朋友可以參考下
    2022-01-01
  • Redis?腳本和連接命令示例詳解

    Redis?腳本和連接命令示例詳解

    Redis腳本是一種可以實(shí)現(xiàn)復(fù)雜任務(wù)的腳本語言,可以用來快速履行復(fù)雜任務(wù),靈活處理數(shù)據(jù)管理和管理復(fù)雜的利用場景,這篇文章主要介紹了Redis?腳本和連接命令,需要的朋友可以參考下
    2023-09-09
  • 手把手教你用Redis 實(shí)現(xiàn)點(diǎn)贊功能并且與數(shù)據(jù)庫同步

    手把手教你用Redis 實(shí)現(xiàn)點(diǎn)贊功能并且與數(shù)據(jù)庫同步

    本文主要介紹了Redis 實(shí)現(xiàn)點(diǎn)贊功能并且與數(shù)據(jù)庫同步,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2022-05-05
  • Redis實(shí)現(xiàn)主從復(fù)制方式(Master&Slave)

    Redis實(shí)現(xiàn)主從復(fù)制方式(Master&Slave)

    這篇文章主要介紹了Redis實(shí)現(xiàn)主從復(fù)制方式(Master&Slave),具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2022-06-06
  • 解決Redis報(bào)錯(cuò)MISCONF?Redis?is?configured?to?save?RDB?snapshots

    解決Redis報(bào)錯(cuò)MISCONF?Redis?is?configured?to?save?RDB?snap

    這篇文章主要給大家介紹了關(guān)于如何解決Redis報(bào)錯(cuò)MISCONF?Redis?is?configured?to?save?RDB?snapshots的相關(guān)資料,文中通過代碼介紹的非常詳細(xì),需要的朋友可以參考下
    2023-11-11
  • Redis主從復(fù)制問題和擴(kuò)容問題的解決思路

    Redis主從復(fù)制問題和擴(kuò)容問題的解決思路

    這篇文章主要介紹了Redis主從復(fù)制問題和擴(kuò)容問題的解決思路,其中擴(kuò)容問題的解決思路來自Redis作者,需要的朋友可以參考下
    2014-06-06

最新評(píng)論