很久前參加過今日頭條的面試,遇到一個題,目前半部分是如何實現 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緩存,使得放入和移除都是 O(1) 的,我們需要把訪問次序維護起來,但是不能通過內存中的真實排序來反應,有一種方案就是使用雙向鏈表。
基於 HashMap 和 雙向鏈表實現 LRU 的
整體的設計思路是,可以使用 HashMap 存儲 key,這樣可以做到 save 和 get key的時間都是 O(1),而 HashMap 的 Value 記錄需要緩存數據在 LRU 存儲中的槽。
而 LRU 存儲是基於雙向鏈表實現的,下面的圖演示了它的原理。其中 h 代表雙向鏈表的表頭,t 代表尾部。如果存儲滿了,可以通過 O(1) 的時間淘汰掉雙向鏈表的尾部,並更新隊頭。
下面總結一下核心操作的步驟:
- save(key),首先通過 hash 算法,在key space 找到 key,並且嘗試把數據存儲到LRU空間,如果LRU空間足夠,則不需要淘汰舊的內容;如果緩存空間不足,會淘汰掉 tail 指向的內容,並更新隊頭,存儲後返回使用槽下標,更新key space 的value。
- get(key),通過 hash 找到 key,然後通過 value 找到 LRU空間對應的槽,更新LRU指向關係。
完整基於 Java 的代碼參考如下
class DLinkedNode {
int 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(int 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(int 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;
}
}
那麼問題的後半部分,是 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。
總結
看來,雖然一個簡單的概念,在工業界的產品中,爲了追求空間的利用率,也會採用權衡的實現方案。