【Redis】LRU算法和Redis的LRU實現

時間  2019-12-13
標籤 Redis lru 算法 redis 實現 欄目 Redis 简体版
原文   原文鏈接

LRU原理

在通常標準的操做系統教材裏，會用下面的方式來演示 LRU 原理，假設內存只能容納3個頁大小，按照 7 0 1 2 0 3 0 4 的次序訪問頁。假設內存按照棧的方式來描述訪問時間，在上面的，是最近訪問的，在下面的是，最遠時間訪問的，LRU就是這樣工做的。node

可是若是讓咱們本身設計一個基於 LRU 的緩存，這樣設計可能問題不少，這段內存按照訪問時間進行了排序，會有大量的內存拷貝操做，因此性能確定是不能接受的。redis

那麼如何設計一個LRU緩存，使得放入和移除都是 O(1) 的，咱們須要把訪問次序維護起來，可是不能經過內存中的真實排序來反應，有一種方案就是使用雙向鏈表。算法

 

實現LRU

1.用一個數組來存儲數據，給每個數據項標記一個訪問時間戳，每次插入新數據項的時候，先把數組中存在的數據項的時間戳自增，並將新數據項的時間戳置爲0並插入到數組中。每次訪問數組中的數據項的時候，將被訪問的數據項的時間戳置爲0。當數組空間已滿時，將時間戳最大的數據項淘汰。數組

2.利用一個鏈表來實現，每次新插入數據的時候將新數據插到鏈表的頭部；每次緩存命中（即數據被訪問），則將數據移到鏈表頭部；那麼當鏈表滿的時候，就將鏈表尾部的數據丟棄。緩存

3.利用鏈表和hashmap。當須要插入新的數據項的時候，若是新數據項在鏈表中存在（通常稱爲命中），則把該節點移到鏈表頭部，若是不存在，則新建一個節點，放到鏈表頭部，若緩存滿了，則把鏈表最後一個節點刪除便可。在訪問數據的時候，若是數據項在鏈表中存在，則把該節點移到鏈表頭部，不然返回-1。這樣一來在鏈表尾部的節點就是最近最久未訪問的數據項。app

對於第一種方法，須要不停地維護數據項的訪問時間戳，另外，在插入數據、刪除數據以及訪問數據時，時間複雜度都是O(n)。對於第二種方法，鏈表在定位數據的時候時間複雜度爲O(n)。因此在通常使用第三種方式來是實現LRU算法。dom

 

基於 HashMap 和 雙向鏈表實現 LRU 的

總體的設計思路是，可使用 HashMap 存儲 key，這樣能夠作到 save 和 get key的時間都是 O(1)，而 HashMap 的 Value 指向雙向鏈表實現的 LRU 的 Node 節點，如圖所示。ide

LRU 存儲是基於雙向鏈表實現的，下面的圖演示了它的原理。其中 head 表明雙向鏈表的表頭，tail 表明尾部。首先預先設置 LRU 的容量，若是存儲滿了，能夠經過 O(1) 的時間淘汰掉雙向鏈表的尾部，每次新增和訪問數據，均可以經過 O(1)的效率把新的節點增長到對頭，或者把已經存在的節點移動到隊頭。post

下面展現了，預設大小是 3 的，LRU存儲的在存儲和訪問過程當中的變化。爲了簡化圖複雜度，圖中沒有展現 HashMap部分的變化，僅僅演示了上圖 LRU 雙向鏈表的變化。咱們對這個LRU緩存的操做序列以下：性能

save("key1", 7)

save("key2", 0)

save("key3", 1)

save("key4", 2)

get("key2")

save("key5", 3)

get("key2")

save("key6", 4)

相應的 LRU 雙向鏈表部分變化以下：

總結一下核心操做的步驟:

  1. save(key, value)，首先在 HashMap 找到 Key 對應的節點，若是節點存在，更新節點的值，並把這個節點移動隊頭。若是不存在，須要構造新的節點，而且嘗試把節點塞到隊頭，若是LRU空間不足，則經過 tail 淘汰掉隊尾的節點，同時在 HashMap 中移除 Key。
  2. get(key)，經過 HashMap 找到 LRU 鏈表節點，由於根據LRU 原理，這個節點是最新訪問的，因此要把節點插入到隊頭，而後返回緩存的值。

 完整基於 Java 的代碼參考以下

class DLinkedNode {
    String key;
    int value;
    DLinkedNode pre;
    DLinkedNode post;
}

LRU Cache

public class LRUCache {
   
    private Hashtable<Integer, DLinkedNode>
            cache = new Hashtable<Integer, DLinkedNode>();
    private int count;
    private int capacity;
    private DLinkedNode head, tail;

    public LRUCache(int capacity) {
        this.count = 0;
        this.capacity = capacity;

        head = new DLinkedNode();
        head.pre = null;

        tail = new DLinkedNode();
        tail.post = null;

        head.post = tail;
        tail.pre = head;
    }

    public int get(String key) {

        DLinkedNode node = cache.get(key);
        if(node == null){
            return -1; // should raise exception here.
        }

        // move the accessed node to the head;
        this.moveToHead(node);

        return node.value;
    }


    public void set(String key, int value) {
        DLinkedNode node = cache.get(key);

        if(node == null){

            DLinkedNode newNode = new DLinkedNode();
            newNode.key = key;
            newNode.value = value;

            this.cache.put(key, newNode);
            this.addNode(newNode);

            ++count;

            if(count > capacity){
                // pop the tail
                DLinkedNode tail = this.popTail();
                this.cache.remove(tail.key);
                --count;
            }
        }else{
            // update the value.
            node.value = value;
            this.moveToHead(node);
        }
    }
    /**
     * Always add the new node right after head;
     */
    private void addNode(DLinkedNode node){
        node.pre = head;
        node.post = head.post;

        head.post.pre = node;
        head.post = node;
    }

    /**
     * Remove an existing node from the linked list.
     */
    private void removeNode(DLinkedNode node){
        DLinkedNode pre = node.pre;
        DLinkedNode post = node.post;

        pre.post = post;
        post.pre = pre;
    }

    /**
     * Move certain node in between to the head.
     */
    private void moveToHead(DLinkedNode node){
        this.removeNode(node);
        this.addNode(node);
    }

    // pop the current tail.
    private DLinkedNode popTail(){
        DLinkedNode res = tail.pre;
        this.removeNode(res);
        return res;
    }
}

 

繼承LinkedHashMap的簡單實現：

LinkedHashMap底層就是用的HashMap加雙鏈表實現的，並且自己已經實現了按照訪問順序的存儲。此外，LinkedHashMap中自己就實現了一個方法removeEldestEntry用於判斷是否須要移除最不常讀取的數，方法默認是直接返回false，不會移除元素，因此須要重寫該方法。即當緩存滿後就移除最不經常使用的數。

public class LRUCache<K, V> extends LinkedHashMap<K, V> {

    private final int CACHE_SIZE;

    // 這裏就是傳遞進來最多能緩存多少數據
    public LRUCache(int cacheSize) {
        // 設置一個hashmap的初始大小，最後一個true指的是讓linkedhashmap按照訪問順序來進行排序，最近訪問的放在頭，最老訪問的就在尾
        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
        CACHE_SIZE = cacheSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry eldest) {
        // 當map中的數據量大於指定的緩存個數的時候，就自動刪除最老的數據
        return size() > CACHE_SIZE;
    }
}

那麼問題的後半部分，是 Redis 如何實現，這個問題這麼問確定是有坑的，那就是redis確定不是這樣實現的。

Redis的LRU實現

若是按照HashMap和雙向鏈表實現，須要額外的存儲存放 next 和 prev 指針，犧牲比較大的存儲空間，顯然是不划算的。因此Redis採用了一個近似的作法，就是隨機取出若干個key，而後按照訪問時間排序後，淘汰掉最不常用的，具體分析以下：

爲了支持LRU，Redis 2.8.19中使用了一個全局的LRU時鐘，server.lruclock，定義以下，

#define REDIS_LRU_BITS 24
unsigned lruclock:REDIS_LRU_BITS; /* Clock for LRU eviction */

默認的LRU時鐘的分辨率是1秒，能夠經過改變REDIS_LRU_CLOCK_RESOLUTION宏的值來改變，Redis會在serverCron()中調用updateLRUClock按期的更新LRU時鐘，更新的頻率和hz參數有關，默認爲100ms一次，以下，

#define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
#define REDIS_LRU_CLOCK_RESOLUTION 1 /* LRU clock resolution in seconds */

void updateLRUClock(void) {
    server.lruclock = (server.unixtime / REDIS_LRU_CLOCK_RESOLUTION) &
                                                REDIS_LRU_CLOCK_MAX;
}

server.unixtime是系統當前的unix時間戳，當 lruclock 的值超出REDIS_LRU_CLOCK_MAX時，會從頭開始計算，因此在計算一個key的最長沒有訪問時間時，可能key自己保存的lru訪問時間會比當前的lrulock還要大，這個時候須要計算額外時間，以下，

/* Given an object returns the min number of seconds the object was never
 * requested, using an approximated LRU algorithm. */
unsigned long estimateObjectIdleTime(robj *o) {
    if (server.lruclock >= o->lru) {
        return (server.lruclock - o->lru) * REDIS_LRU_CLOCK_RESOLUTION;
    } else {
        return ((REDIS_LRU_CLOCK_MAX - o->lru) + server.lruclock) *
                    REDIS_LRU_CLOCK_RESOLUTION;
    }
}

Redis支持和LRU相關淘汰策略包括，

  • volatile-lru 設置了過時時間的key參與近似的lru淘汰策略
  • allkeys-lru 全部的key均參與近似的lru淘汰策略

當進行LRU淘汰時，Redis按以下方式進行的，

......
            /* volatile-lru and allkeys-lru policy */
            else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
                server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
            {
                for (k = 0; k < server.maxmemory_samples; k++) {
                    sds thiskey;
                    long thisval;
                    robj *o;

                    de = dictGetRandomKey(dict);
                    thiskey = dictGetKey(de);
                    /* When policy is volatile-lru we need an additional lookup
                     * to locate the real key, as dict is set to db->expires. */
                    if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
                        de = dictFind(db->dict, thiskey);
                    o = dictGetVal(de);
                    thisval = estimateObjectIdleTime(o);

                    /* Higher idle time is better candidate for deletion */
                    if (bestkey == NULL || thisval > bestval) {
                        bestkey = thiskey;
                        bestval = thisval;
                    }
                }
            }
            ......

Redis會基於server.maxmemory_samples配置選取固定數目的key，而後比較它們的lru訪問時間，而後淘汰最近最久沒有訪問的key，maxmemory_samples的值越大，Redis的近似LRU算法就越接近於嚴格LRU算法，可是相應消耗也變高，對性能有必定影響，樣本值默認爲5。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程