LRU原理和Redis實現——一個今日頭條的面試題(轉載)

好久前參加過今日頭條的面試，遇到一個題，目前半部分是如何實現 LRU，後半部分是 Redis 中如何實現 LRU。

個人第一反應是操做系統課程裏學過，應該是內存不夠的場景下，淘汰舊內容的策略。LRU ... Least Recent Used，淘汰掉最不常常使用的。能夠稍微多補充兩句，由於計算機體系結構中，最大的最可靠的存儲是硬盤，它容量很大，而且內容能夠固化，可是訪問速度很慢，因此須要把使用的內容載入內存中；內存速度很快，可是容量有限，而且斷電後內容會丟失，而且爲了進一步提高性能，還有CPU內部的 L1 Cache，L2 Cache等概念。由於速度越快的地方，它的單位成本越高，容量越小，新的內容不斷被載入，舊的內容確定要被淘汰，因此就有這樣的使用背景。

LRU原理

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

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

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

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

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

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

下面展現了，預設大小是 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 鏈表節點，把節點插入到隊頭，返回緩存的值。

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

1.  
   class DLinkedNode {
2.  
   String key;
3.  
   int value;
4.  
   DLinkedNode pre;
5.  
   DLinkedNode post;
6.  
   }

LRU Cache

1.  
   public class LRUCache {
2.  
    
3.  
   private Hashtable<Integer, DLinkedNode>
4.  
   cache = new Hashtable<Integer, DLinkedNode>();
5.  
   private int count;
6.  
   private int capacity;
7.  
   private DLinkedNode head, tail;
8.  
    
9.  
   public LRUCache(int capacity) {
10.  
    this.count = 0;
11.  
    this.capacity = capacity;
12.  
     
13.  
    head = new DLinkedNode();
14.  
    head.pre = null;
15.  
     
16.  
    tail = new DLinkedNode();
17.  
    tail.post = null;
18.  
     
19.  
    head.post = tail;
20.  
    tail.pre = head;
21.  
    }
22.  
     
23.  
    public int get(String key) {
24.  
     
25.  
    DLinkedNode node = cache.get(key);
26.  
    if(node == null){
27.  
    return -1; // should raise exception here.
28.  
    }
29.  
     
30.  
    // move the accessed node to the head;
31.  
    this.moveToHead(node);
32.  
     
33.  
    return node.value;
34.  
    }
35.  
     
36.  
     
37.  
    public void set(String key, int value) {
38.  
    DLinkedNode node = cache.get(key);
39.  
     
40.  
    if(node == null){
41.  
     
42.  
    DLinkedNode newNode = new DLinkedNode();
43.  
    newNode.key = key;
44.  
    newNode.value = value;
45.  
     
46.  
    this.cache.put(key, newNode);
47.  
    this.addNode(newNode);
48.  
     
49.  
    ++count;
50.  
     
51.  
    if(count > capacity){
52.  
    // pop the tail
53.  
    DLinkedNode tail = this.popTail();
54.  
    this.cache.remove(tail.key);
55.  
    --count;
56.  
    }
57.  
    }else{
58.  
    // update the value.
59.  
    node.value = value;
60.  
    this.moveToHead(node);
61.  
    }
62.  
    }
63.  
    /**
64.  
    * Always add the new node right after head;
65.  
    */
66.  
    private void addNode(DLinkedNode node){
67.  
    node.pre = head;
68.  
    node.post = head.post;
69.  
     
70.  
    head.post.pre = node;
71.  
    head.post = node;
72.  
    }
73.  
     
74.  
    /**
75.  
    * Remove an existing node from the linked list.
76.  
    */
77.  
    private void removeNode(DLinkedNode node){
78.  
    DLinkedNode pre = node.pre;
79.  
    DLinkedNode post = node.post;
80.  
     
81.  
    pre.post = post;
82.  
    post.pre = pre;
83.  
    }
84.  
     
85.  
    /**
86.  
    * Move certain node in between to the head.
87.  
    */
88.  
    private void moveToHead(DLinkedNode node){
89.  
    this.removeNode(node);
90.  
    this.addNode(node);
91.  
    }
92.  
     
93.  
    // pop the current tail.
94.  
    private DLinkedNode popTail(){
95.  
    DLinkedNode res = tail.pre;
96.  
    this.removeNode(res);
97.  
    return res;
98.  
    }
99.  
    }

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

Redis的LRU實現

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

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

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

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

1.  
   #define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
2.  
   #define REDIS_LRU_CLOCK_RESOLUTION 1 /* LRU clock resolution in seconds */
3.  
    
4.  
   void updateLRUClock(void) {
5.  
   server.lruclock = (server.unixtime / REDIS_LRU_CLOCK_RESOLUTION) &
6.  
   REDIS_LRU_CLOCK_MAX;
7.  
   }

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

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

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

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

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

1.  
   ......
2.  
   /* volatile-lru and allkeys-lru policy */
3.  
   else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
4.  
   server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
5.  
   {
6.  
   for (k = 0; k < server.maxmemory_samples; k++) {
7.  
   sds thiskey;
8.  
   long thisval;
9.  
   robj *o;
10.  
     
11.  
    de = dictGetRandomKey(dict);
12.  
    thiskey = dictGetKey(de);
13.  
    /* When policy is volatile-lru we need an additional lookup
14.  
    * to locate the real key, as dict is set to db->expires. */
15.  
    if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
16.  
    de = dictFind(db->dict, thiskey);
17.  
    o = dictGetVal(de);
18.  
    thisval = estimateObjectIdleTime(o);
19.  
     
20.  
    /* Higher idle time is better candidate for deletion */
21.  
    if (bestkey == NULL || thisval > bestval) {
22.  
    bestkey = thiskey;
23.  
    bestval = thisval;
24.  
    }
25.  
    }
26.  
    }
27.  
    ......

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

總結

看來，雖然一個簡單的概念，在工業界的產品中，爲了追求空間的利用率，也會採用權衡的實現方案。

傳送門 https://zhuanlan.zhihu.com/p/34133067

 

原文：https://blog.csdn.net/hopeztm/article/details/79547052

關於linkedhashmap實現LRU：https://www.cnblogs.com/lzrabbit/p/3734850.html