1. 程式人生 > >LRU原理和Redis實現——一個今日頭條的面試題

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

滿了 存儲空間 當前 node 硬盤 java 原理 remove http

看了評論,發現有些地方有問題,更新了圖和一些描述,希望可以更清晰一些,也歡迎關註,還會有幹貨文章

--------

很久前參加過今日頭條的面試,遇到一個題,目前半部分是如何實現 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 存儲是基於雙向鏈表實現的,下面的圖演示了它的原理。其中 head 代表雙向鏈表的表頭,tail 代表尾部。首先預先設置 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 雙向鏈表部分變化如下:

s = save, g = get

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

save(key, value),首先在 HashMap 找到 Key 對應的節點,如果節點存在,更新節點的值,並把這個節點移動隊頭。如果不存在,需要構造新的節點,並且嘗試把節點塞到隊頭,如果LRU空間不足,則通過 tail 淘汰掉隊尾的節點,同時在 HashMap 中移除 Key。

get(key),通過 HashMap 找到 LRU 鏈表節點,因為根據LRU 原理,這個節點是最新訪問的,所以要把節點插入到隊頭,然後返回緩存的值。

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

classDLinkedNode{Stringkey;intvalue;DLinkedNodepre;DLinkedNodepost;}

LRU Cache

publicclassLRUCache{privateHashtablecache=newHashtable();privateintcount;privateintcapacity;privateDLinkedNodehead,tail;publicLRUCache(intcapacity){this.count=0;this.capacity=capacity;head=newDLinkedNode();head.pre=null;tail=newDLinkedNode();tail.post=null;head.post=tail;tail.pre=head;}publicintget(Stringkey){DLinkedNodenode=cache.get(key);if(node==null){return-1;// should raise exception here.}// move the accessed node to the head;this.moveToHead(node);returnnode.value;}publicvoidset(Stringkey,intvalue){DLinkedNodenode=cache.get(key);if(node==null){DLinkedNodenewNode=newDLinkedNode();newNode.key=key;newNode.value=value;this.cache.put(key,newNode);this.addNode(newNode);++count;if(count>capacity){// pop the tailDLinkedNodetail=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;*/privatevoidaddNode(DLinkedNodenode){node.pre=head;node.post=head.post;head.post.pre=node;head.post=node;}/*** Remove an existing node from the linked list.*/privatevoidremoveNode(DLinkedNodenode){DLinkedNodepre=node.pre;DLinkedNodepost=node.post;pre.post=post;post.pre=pre;}/*** Move certain node in between to the head.*/privatevoidmoveToHead(DLinkedNodenode){this.removeNode(node);this.addNode(node);}// pop the current tail.privateDLinkedNodepopTail(){DLinkedNoderes=tail.pre;this.removeNode(res);returnres;}}

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

Redis的LRU實現

如果按照HashMap和雙向鏈表實現,需要額外的存儲存放 next 和 prev 指針,犧牲比較大的存儲空間,顯然是不劃算的。所以Redis采用了一個近似的做法,就是隨機取出若幹個key,然後按照訪問時間排序後,淘汰掉最不經常使用的,具體分析如下:

為了支持LRU,Redis 2.8.19中使用了一個全局的LRU時鐘,server.lruclock,定義如下,

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

默認的LRU時鐘的分辨率是1秒,可以通過改變REDIS_LRU_CLOCK_RESOLUTION宏的值來改變,Redis會在serverCron()中調用updateLRUClock定期的更新LRU時鐘,更新的頻率和hz參數有關,默認為100ms一次,如下,

#define REDIS_LRU_CLOCK_MAX ((1lru */#define REDIS_LRU_CLOCK_RESOLUTION 1/* LRU clock resolution in seconds */voidupdateLRUClock(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. */unsignedlongestimateObjectIdleTime(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 */elseif(server.maxmemory_policy==REDIS_MAXMEMORY_ALLKEYS_LRU||server.maxmemory_policy==REDIS_MAXMEMORY_VOLATILE_LRU){for(k=0;kexpires. */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。

總結

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

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