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