redis的LRU算法（一）

最近加班比较累，完全不想写作了。。

刚看到一篇有趣的文章，是redis的作者antirez对redis的LRU算法的回顾。LRU算法是Least Recently Used的意思，将最近最少使用的资源丢掉。Redis经常被用作cache，如果能够将不常用的key移除，尽量保留常用的，那内存的利用率就相当高了。当然，LRU也有弱点，考虑下面一种情况：

~~~~~A~~~~~A~~~~~A~~~~A~~~~~A~~~~~A~~|
~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~~B~|
~~~~~~~~~~C~~~~~~~~~C~~~~~~~~~C~~~~~~|
~~~~~D~~~~~~~~~~D~~~~~~~~~D~~~~~~~~~D|

假设有4个key，A以5秒1次的频率被访问，B访问频率是2秒1次，C和D的访问频率都是10秒1次。因为B有最高的访问频率，所以B的空闲访问时间是最小的。它的上次访问时间也是第二最近的。但是D是一个特例，它的访问频率是10秒1次，但是它的访问时间是最近的。

当然，长期来看，这个算法还是不错的。通常访问频率高的key都有相对比较小的空闲时间。LRU算法会换掉最近最少使用的key，即空闲时间最长的。这个算法实现起来非常简单，我们秩序要跟踪一个key上次访问的时间即可，甚至有时候都不用，只要维持一个链表，有访问的就移动到表头，需要换掉元素的时候，就移除链表尾部的。

Redis最早并不支持LRU替换。通过修改Redis对象结构，作者挤出了24bit空间来做这个事情。因为指针太大，也没有空间来用链表实现。24bit用来存时间戳的低位已经足够了，可以支撑194天了，key的数据刷新频繁，够用了。

如何选择最大空闲时间的key来换出也是一个问题，Redis的key存放在一个平坦的哈希表里，添加一个额外的数据结构来完成代价太大。既然LRU是理想换页的一个渐近算法，我们何不尝试下LRU的渐近算法呢？

Redis的原始实现非常简单：当需要换出一个Key的时候，选任意3个key，，换出其中空闲时间最长的。相当于对整个key空间进行随机采样，并换出较好的选择。后来这个算法演变成N个随机key，算法优化后，默认变成采样5个key，速度没有损失。虽然实现是如此简单，但工作起来非常好。如果你仔细思考，你会发现你不可能用这个算法作出最佳决定，但是你也不大可能作出非常坏的决定。如果数据集里有一堆经常访问的key，5选1不大可能都挑中“热”的key。