《三次给你聊清楚Redis》之Redis咋实现的

randomLevel()
level := 1
// random()返回一个[0...1)的随机数
while random() < p and level < MaxLevel do
level := level + 1
return level

randomLevel()的伪码中包含两个参数，一个是p，一个是MaxLevel。在Redis的skiplist实现中，这两个参数的取值为：

p = 1/4
MaxLevel = 32

2.2.2skiplist的算法性能分析

在这一部分，我们来简单分析一下skiplist的时间复杂度和空间复杂度，以便对于skiplist的性能有一个直观的了解。如果你不是特别偏执于算法的性能分析，那么可以暂时跳过这一小节的内容。

我们先来计算一下每个节点所包含的平均指针数目（概率期望）。节点包含的指针数目，相当于这个算法在空间上的额外开销(overhead)，可以用来度量空间复杂度。

根据前面randomLevel()的伪码，我们很容易看出，产生越高的节点层数，概率越低。定量的分析如下：

• 节点层数至少为1。而大于1的节点层数，满足一个概率分布。
• 节点层数恰好等于1的概率为1-p。
• 节点层数大于等于2的概率为p，而节点层数恰好等于2的概率为p(1-p)。
• 节点层数大于等于3的概率为p^2，而节点层数恰好等于3的概率为p^2(1-p)。
• 节点层数大于等于4的概率为p^3，而节点层数恰好等于4的概率为p^3(1-p)。
• ......

因此，一个节点的平均层数（也即包含的平均指针数目），计算如下：

​

现在很容易计算出：

• 当p=1/2时，每个节点所包含的平均指针数目为2；
• 当p=1/4时，每个节点所包含的平均指针数目为1.33。这也是Redis里的skiplist实现在空间上的开销。

接下来，为了分析时间复杂度，我们计算一下skiplist的平均查找长度。查找长度指的是查找路径上跨越的跳数，而查找过程中的比较次数就等于查找长度加1。以前面图中标出的查找23的查找路径为例，从左上角的头结点开始，一直到结点22，查找长度为6。

为了计算查找长度，这里我们需要利用一点小技巧。我们注意到，每个节点插入的时候，它的层数是由随机函数randomLevel()计算出来的，而且随机的计算不依赖于其它节点，每次插入过程都是完全独立的。所以，从统计上来说，一个skiplist结构的形成与节点的插入顺序无关。

这样的话，为了计算查找长度，我们可以将查找过程倒过来看，从右下方第1层上最后到达的那个节点开始，沿着查找路径向左向上回溯，类似于爬楼梯的过程。我们假设当回溯到某个节点的时候，它才被插入，这虽然相当于改变了节点的插入顺序，但从统计上不影响整个skiplist的形成结构。

现在假设我们从一个层数为i的节点x出发，需要向左向上攀爬k层。这时我们有两种可能：

• 如果节点x有第(i+1)层指针，那么我们需要向上走。这种情况概率为p。
• 如果节点x没有第(i+1)层指针，那么我们需要向左走。这种情况概率为(1-p)。

​

用C(k)表示向上攀爬k个层级所需要走过的平均查找路径长度（概率期望），那么：

C(0)=0
C(k)=(1-p)×(上图中情况b的查找长度) + p×(上图中情况c的查找长度)

代入，得到一个差分方程并化简：

C(k)=(1-p)(C(k)+1) + p(C(k-1)+1)
C(k)=1/p+C(k-1)
C(k)=k/p

这个结果的意思是，我们每爬升1个层级，需要在查找路径上走1/p步。而我们总共需要攀爬的层级数等于整个skiplist的总层数-1。

那么接下来我们需要分析一下当skiplist中有n个节点的时候，它的总层数的概率均值是多少。这个问题直观上比较好理解。根据节点的层数随机算法，容易得出：

• 第1层链表固定有n个节点；
• 第2层链表平均有n*p个节点；
• 第3层链表平均有n*p^2个节点；
• ...

所以，从第1层到最高层，各层链表的平均节点数是一个指数递减的等比数列。容易推算出，总层数的均值为log1/pn，而最高层的平均节点数为1/p。

综上，粗略来计算的话，平均查找长度约等于：

• C(log1/pn-1)=(log1/pn-1)/p

即，平均时间复杂度为O(log n)。

当然，这里的时间复杂度分析还是比较粗略的。比如，沿着查找路径向左向上回溯的时候，可能先到达左侧头结点，然后沿头结点一路向上；还可能先到达最高层的节点，然后沿着最高层链表一路向左。但这些细节不影响平均时间复杂度的最后结果。另外，这里给出的时间复杂度只是一个概率平均值，但实际上计算一个精细的概率分布也是有可能的。

详情还请参见William Pugh的论文《Skip Lists: A Probabilistic Alternative to Balanced Trees》。

2.2.3skiplist与平衡树、哈希表的比较

• skiplist和各种平衡树（如AVL、红黑树等）的元素是有序排列的，而哈希表不是有序的。因此，在哈希表上只能做单个key的查找，不适宜做范围查找。所谓范围查找，指的是查找那些大小在指定的两个值之间的所有节点。
• 在做范围查找的时候，平衡树比skiplist操作要复杂。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在skiplist上进行范围查找就非常简单，只需要在找到小值之后，对第1层链表进行若干步的遍历就可以实现。
• 平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而skiplist的插入和删除只需要修改相邻节点的指针，操作简单又快速。
• 从内存占用上来说，skiplist比平衡树更灵活一些。一般来说，平衡树每个节点包含2个指针（分别指向左右子树），而skiplist每个节点包含的指针数目平均为1/(1-p)，具体取决于参数p的大小。如果像Redis里的实现一样，取p=1/4，那么平均每个节点包含1.33个指针，比平衡树更有优势。
• 查找单个key，skiplist和平衡树的时间复杂度都为O(log n)，大体相当；而哈希表在保持较低的哈希值冲突概率的前提下，查找时间复杂度接近O(1)，性能更高一些。所以我们平常使用的各种Map或dictionary结构，大都是基于哈希表实现的。
• 从算法实现难度上来比较，skiplist比平衡树要简单得多。

2.2.4Redis中的skiplist和经典有何不同

• 分数(score)允许重复，即skiplist的key允许重复。这在最开始介绍的经典skiplist中是不允许的。
• 在比较时，不仅比较分数（相当于skiplist的key），还比较数据本身。在Redis的skiplist实现中，数据本身的内容唯一标识这份数据，而不是由key来唯一标识。另外，当多个元素分数相同的时候，还需要根据数据内容来进字典排序。
• 第1层链表不是一个单向链表，而是一个双向链表。这是为了方便以倒序方式获取一个范围内的元素。
• 在skiplist中可以很方便地计算出每个元素的排名(rank)。

2.2.5作者的话

最后我们看看，对于这个问题，Redis的作者 @antirez 是怎么说的：

There are a few reasons:

1) They are not very memory intensive. It's up to you basically. Changing parameters about the probability of a node to have a given number of levels will make then less memory intensive than btrees.

2) A sorted set is often target of many ZRANGE or ZREVRANGE operations, that is, traversing the skip list as a linked list. With this operation the cache locality of skip lists is at least as good as with other kind of balanced trees.

3) They are simpler to implement, debug, and so forth. For instance thanks to the skip list simplicity I received a patch (already in Redis master) with augmented skip lists implementing ZRANK in O(log(N)). It required little changes to the code.

有几个原因：

1）它们的记忆力不是很强。基本上由你决定。更改有关节点具有给定数量级别的概率的参数将使内存密集度低于btree。

2）排序集通常是许多Zrange或Zrevrange操作的目标，即作为链表遍历跳过列表。通过此操作，跳过列表的缓存区域性至少与其他类型的平衡树一样好。

3）它们易于实现、调试等。例如，由于跳过列表的简单性，我收到了一个补丁（已经在redis master中），其中包含在o（log（n））中实现zrank的扩展跳过列表。它只需要对代码稍作修改。

2.3HyperLogLog 专栏

HyperLogLog 是一种概率数据结构，用来估算数据的基数。数据集可以是网站访客的 IP 地址，E-mail 邮箱或者用户 ID。

基数就是指一个集合中不同值的数目，比如 a, b, c, d 的基数就是 4，a, b, c, d, a 的基数还是 4。虽然 a 出现两次，只会被计算一次。

使用 Redis 统计集合的基数一般有三种方法，分别是使用 Redis 的 HashMap，BitMap 和 HyperLogLog。前两个数据结构在集合的数量级增长时，所消耗的内存会大大增加，但是 HyperLogLog 则不会。

Redis 的 HyperLogLog 通过牺牲准确率来减少内存空间的消耗，只需要12K内存，在标准误差0.81%的前提下，能够统计2^64个数据。所以 HyperLogLog 是否适合在比如统计日活月活此类的对精度要不不高的场景。

这是一个很惊人的结果，以如此小的内存来记录如此大数量级的数据基数。下面我们就带大家来深入了解一下 HyperLogLog 的使用，基础原理，源码实现和具体的试验数据分析。

2.3.1HyperLogLog 在 Redis 中的使用

Redis 提供了 PFADD 、 PFCOUNT 和 PFMERGE 三个命令来供用户使用 HyperLogLog。

PFADD 用于向 HyperLogLog 添加元素。

> PFADD visitors alice bob carol

(integer) 1

> PFCOUNT visitors

(integer) 3

如果 HyperLogLog 估计的近似基数在 PFADD 命令执行之后出现了变化， 那么命令返回 1 ， 否则返回 0 。 如果命令执行时给定的键不存在， 那么程序将先创建一个空的 HyperLogLog 结构， 然后再执行命令。

PFCOUNT 命令会给出 HyperLogLog 包含的近似基数。在计算出基数后， PFCOUNT 会将值存储在 HyperLogLog 中进行缓存，知道下次 PFADD 执行成功前，就都不需要再次进行基数的计算。

PFMERGE 将多个 HyperLogLog 合并为一个 HyperLogLog ， 合并后的 HyperLogLog 的基数接近于所有输入 HyperLogLog 的并集基数。

> PFADD customers alice dan

(integer) 1

> PFMERGE everyone visitors customers

OK

> PFCOUNT everyone

(integer) 4

2.3.2内存消耗对比实验

我们下面就来通过实验真实对比一下下面三种数据结构的内存消耗，HashMap、BitMap 和 HyperLogLog。

我们首先使用 Lua 脚本向 Redis 对应的数据结构中插入一定数量的数，然后执行 bgsave 命令，最后使用 redis-rdb-tools 的 rdb 的命令查看各个键所占的内存大小。

下面是 Lua 的脚本

local key = KEYS[1]

local size = tonumber(ARGV[1])

local method = tonumber(ARGV[2])



for i=1,size,1 do

if (method == 0)

then

redis.call('hset',key,i,1)

elseif (method == 1)

then

redis.call('pfadd',key, i)

else

redis.call('setbit', key, i, 1)

end

end

我们在通过 redis-cli 的 script load 命令将 Lua 脚本加载到 Redis 中，然后使用 evalsha 命令分别向 HashMap、HyperLogLog 和 BitMap 三种数据结构中插入了一千万个数，然后使用 rdb 命令查看各个结构内存消耗。

我们进行了两轮实验，分别插入一万数字和一千万数字，三种数据结构消耗的内存统计如下所示。

​

从表中可以明显看出，一万数量级时 BitMap 消耗内存最小， 一千万数量级时 HyperLogLog 消耗内存最小，但是总体来看，HyperLogLog 消耗的内存都是 14392 字节，可见 HyperLogLog 在内存消耗方面有自己的独到之处。

2.3.3基本原理

HyperLogLog 是一种概率数据结构，它使用概率算法来统计集合的近似基数。而它算法的最本源则是伯努利过程。

伯努利过程就是一个抛硬币实验的过程。抛一枚正常硬币，落地可能是正面，也可能是反面，二者的概率都是 1/2 。伯努利过程就是一直抛硬币，直到落地时出现正面位置，并记录下抛掷次数k。比如说，抛一次硬币就出现正面了，此时 k 为 1; 第一次抛硬币是反面，则继续抛，直到第三次才出现正面，此时 k 为 3。

对于 n 次伯努利过程，我们会得到 n 个出现正面的投掷次数值 k1, k2 ... kn , 其中这里的最大值是k_max。

根据一顿数学推导，我们可以得出一个结论： 2^{k_ max} 来作为n的估计值。也就是说你可以根据最大投掷次数近似的推算出进行了几次伯努利过程。

​

下面，我们就来讲解一下 HyperLogLog 是如何模拟伯努利过程，并最终统计集合基数的。

HyperLogLog 在添加元素时，会通过Hash函数，将元素转为64位比特串，例如输入5，便转为101(省略前面的0，下同)。这些比特串就类似于一次抛硬币的伯努利过程。比特串中，0 代表了抛硬币落地是反面，1 代表抛硬币落地是正面，如果一个数据最终被转化了 10010000，那么从低位往高位看，我们可以认为，这串比特串可以代表一次伯努利过程，首次出现 1 的位数为5，就是抛了5次才出现正面。

所以 HyperLogLog 的基本思想是利用集合中数字的比特串第一个 1 出现位置的最大值来预估整体基数，但是这种预估方法存在较大误差，为了改善误差情况，HyperLogLog中引入分桶平均的概念，计算 m 个桶的调和平均值。

​

Redis 中 HyperLogLog 一共分了 2^14 个桶，也就是 16384 个桶。每个桶中是一个 6 bit 的数组。

HyperLogLog 将上文所说的 64 位比特串的低 14 位单独拿出，它的值就对应桶的序号，然后将剩下 50 位中第一次出现 1 的位置值设置到桶中。50位中出现1的位置值最大为50，所以每个桶中的 6 位数组正好可以表示该值。

在设置前，要设置进桶的值是否大于桶中的旧值，如果大于才进行设置，否则不进行设置。

此时为了性能考虑，是不会去统计当前的基数的，而是将 HyperLogLog 头的 card 属性中的标志位置为 1，表示下次进行 pfcount 操作的时候，当前的缓存值已经失效了，需要重新统计缓存值。在后面 pfcount 流程的时候，发现这个标记为失效，就会去重新统计新的基数，放入基数缓存。

在计算近似基数时，就分别计算每个桶中的值，带入到上文的 DV 公式中，进行调和平均和结果修正，就能得到估算的基数值。

2.3.4HyperLogLog 具体对象

我们首先来看一下 HyperLogLog 对象的定义

struct hllhdr {

char magic[4]; /* 魔法值 "HYLL" */

uint8_t encoding; /* 密集结构或者稀疏结构 HLL_DENSE or HLL_SPARSE. */

uint8_t notused[3]; /* 保留位, 全为0. */

uint8_t card[8]; /* 基数大小的缓存 */

uint8_t registers[]; /* 数据字节数组 */

};

HyperLogLog 对象中的 registers 数组就是桶，它有两种存储结构，分别为密集存储结构和稀疏存储结构，两种结构只涉及存储和桶的表现形式，从中我们可以看到 Redis 对节省内存极致地追求。

我们先看相对简单的密集存储结构，它也是十分的简单明了，既然要有 2^14 个 6 bit的桶，那么我就真使用足够多的 uint8_t 字节去表示，只是此时会涉及到字节位置和桶的转换，因为字节有 8 位，而桶只需要 6 位。

所以我们需要将桶的序号转换成对应的字节偏移量 offsetbytes 和其内部的位数偏移量 offsetbits。需要注意的是小端字节序，高位在右侧，需要进行倒转。

当 offset_bits 小于等于2时，说明一个桶就在该字节内，只需要进行倒转就能得到桶的值。

 offset_bits 大于 2 ，则说明一个桶分布在两个字节内，此时需要将两个字节的内容都进行倒置，然后再进行拼接得到桶的值。

Redis 为了方便表达稀疏存储，它将上面三种字节表示形式分别赋予了一条指令。

• ZERO : 一字节，表示连续多少个桶计数为0，前两位为标志00，后6位表示有多少个桶，最大为64。

• XZERO : 两个字节，表示连续多少个桶计数为0，前两位为标志01，后14位表示有多少个桶，最大为16384。

• VAL : 一字节，表示连续多少个桶的计数为多少，前一位为标志1，四位表示连桶内计数，所以最大表示桶的计数为32。后两位表示连续多少个桶。

Redis从稀疏存储转换到密集存储的条件是：

• 任意一个计数值从 32 变成 33，因为 VAL 指令已经无法容纳，它能表示的计数值最大为 32

• 稀疏存储占用的总字节数超过 3000 字节，这个阈值可以通过 hllsparsemax_bytes 参数进行调整。

2.4LRU专栏

2.4.1LRU介绍和代码实现

LRU全称是Least Recently Used，即最近最久未使用的意思。

LRU算法的设计原则是：如果一个数据在最近一段时间没有被访问到，那么在将来它被访问的可能性也很小。也就是说，当限定的空间已存满数据时，应当把最久没有被访问到的数据淘汰。（这一段是找的，让大家理解一下什么是LRU）。

说一下我们什么时候见到过LRU：其实老师们肯定都给大家举过这么个例子：你在图书馆，你把书架子里的书拿到桌子上。。但是桌子是有限的，你有时候不得不把一些书放回去。这就相当于内存和硬盘。这个例子都说过吧？

LRU就是记录你最长时间没看过的书，就把它放回去。在cache那里见过吧

然后最近在研究redis，又看到了这个LRU，所以就想写一下吧。

题目：设计一个结构，这个结构可以查询K-V，但是容量有限，当存不下的时候就要把用的年代最久远的那个东西扔掉。

其实思路很简单，我们维护一个双向链表即可，get也就是使用了，我们就把把它提到最安全的位置。新来的KV就依次放即可。

我们就先写这个双向链表结构

先写节点结构：

	public static class Node<V> {
		public V value;
		public Node<V> last;//前
		public Node<V> next;//后

		public Node(V value) {
			this.value = value;
		}
	}

然后写双向链表结构： 我们没必要把链表操作都写了，分析一下，我们只有三个操作：

1、加节点

2、使用了某个节点就把它调到尾，代表优先级最高

3、把优先级最低的移除，也就是去头部

（不会的，翻我之前的链表操作都有写）

	public static class NodeDoubleLinkedList<V> {
		private Node<V> head;//头
		private Node<V> tail;//尾

		public NodeDoubleLinkedList() {
			this.head = null;
			this.tail = null;
		}

		public void addNode(Node<V> newNode) {
			if (newNode == null) {
				return;
			}
			if (this.head == null) {//头空
				this.head = newNode;
				this.tail = newNode;
			} else {//头不空
				this.tail.next = newNode;
				newNode.last = this.tail;//注意让本节点前指针指向旧尾
				this.tail = newNode;//指向新尾
			}
		}
/*某个点移到最后*/
		public void moveNodeToTail(Node<V> node) {
			if (this.tail == node) {//是尾
				return;
			}
			if (this.head == node) {//是头
				this.head = node.next;
				this.head.last = null;
			} else {//中间
				node.last.next = node.next;
				node.next.last = node.last;
			}
			node.last = this.tail;
			node.next = null;
			this.tail.next = node;
			this.tail = node;
		}
/*删除第一个*/
		public Node<V> removeHead() {
			if (this.head == null) {
				return null;
			}
			Node<V> res = this.head;
			if (this.head == this.tail) {//就一个
				this.head = null;
				this.tail = null;
			} else {
				this.head = res.next;
				res.next = null;
				this.head.last = null;
			}
			return res;
		}

	}

链表操作封装完了就要实现这个结构了。

具体思路代码注释

	public static class MyCache<K, V> {
		//为了kv or vk都能查
		private HashMap<K, Node<V>> keyNodeMap;
		private HashMap<Node<V>, K> nodeKeyMap;
		//用来做优先级
		private NodeDoubleLinkedList<V> nodeList;
		private int capacity;//容量

		public MyCache(int capacity) {
			if (capacity < 1) {//你容量连1都不给，捣乱呢
				throw new RuntimeException("should be more than 0.");
			}
			this.keyNodeMap = new HashMap<K, Node<V>>();
			this.nodeKeyMap = new HashMap<Node<V>, K>();
			this.nodeList = new NodeDoubleLinkedList<V>();
			this.capacity = capacity;
		}

		public V get(K key) {
			if (this.keyNodeMap.containsKey(key)) {
				Node<V> res = this.keyNodeMap.get(key);
				this.nodeList.moveNodeToTail(res);//使用过了就放到尾部
				return res.value;
			}
			return null;
		}

		public void set(K key, V value) {
			if (this.keyNodeMap.containsKey(key)) {
				Node<V> node = this.keyNodeMap.get(key);
				node.value = value;//放新v
				this.nodeList.moveNodeToTail(node);//我们认为放入旧key也是使用过
			} else {
				Node<V> newNode = new Node<V>(value);
				this.keyNodeMap.put(key, newNode);
				this.nodeKeyMap.put(newNode, key);
				this.nodeList.addNode(newNode);//加进去
				if (this.keyNodeMap.size() == this.capacity + 1) {
					this.removeMostUnusedCache();//放不下就去掉优先级最低的
				}
			}
		}

		private void removeMostUnusedCache() {
			//删除头
			Node<V> removeNode = this.nodeList.removeHead();
			K removeKey = this.nodeKeyMap.get(removeNode);
			//删除掉两个map中的记录
			this.nodeKeyMap.remove(removeNode);
			this.keyNodeMap.remove(removeKey);
		}
	}

2.4.2Redis中的LRU算法改进

redis通常使用缓存，是使用一种固定最大内存的使用。当数据达到可使用的最大固定内存时，我们需要通过移除老数据来获取空间。redis作为缓存是否有效的重要标志是如何寻找一种好的策略：删除即将需要使用的数据是一种糟糕的策略，而删除那些很少再次请求的数据则是一种好的策略。
在其他的缓存组件还有个命中率，仅仅表示读请求的比例。访问一个缓存中的keys通常不是分布式的。然而访问经常变化，这意味着不经常访问，相反，有些keys一旦不流行可能会转向最经常访问的keys。 因此，通常一个缓存系统应该尽可能保留那些未来最有可能被访问的keys。针对keys淘汰的策略是：那些未来极少可能被访问的数据应该被移除。
但有一个问题：redis和其他缓存系统不能够预测未来。

LRU算法

缓存系统不能预测未来，原因是：那些很少再次被访问的key也很有可能最近访问相当频繁。如果经常被访问的模式不会突然改变，那么这是一种很有效的策略。然而，“最近经常被访问”似乎更隐晦地标明一种 理念。这种算法被称为LRU算法。最近访问频繁的key相比访问少的key有更高的可能性。
举个例子，这里有4个不同访问周期的key，每一个“~”字符代表一秒，结尾的“|”表示当前时刻。

~~~~~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|

A key每5秒请求一次，B周期是2秒，C、D都是10秒。
访问频率最高的是B，因为它的空闲时间最短，这意味着B是4个key中未来最有可能被访问的key。
同样的A和C目前的空闲时间是2s和6s也能很好地反映它们本身的周期。然而你可以看到不够严谨：D的访问周期是10秒，但它却是4个key中最近被访问的。
当然，在一个很长的运行周期中，LRU算法能工作得很好。通常有一个更高访问频率的key当然有一个更低的空闲周期。LRU算法淘汰最少被访问key，那些有最大空闲周期的key。实现上也相当容易，只需要额外跟踪最近被访问的key即可，有时甚至都需要：把所有我们想要淘汰的对象放到一个链表中，当一个对象访问就移除链表头部元素，当我们要淘汰元素是就直接淘汰链表尾部开始。

redis中的LRU:起因

最初，redis不支持LRU算法。当内存有效性成为一个必须被解决的问题时，后来才加上了。通过修改redis对象结构，在每个key对象增加24bit的空间。没有额外的空间使用链表把所有对象放到一个链表中（大指针），因此需要实现得更加有效，不能因为key淘汰算法而让整个服务改动太大。
24bits的对象已经足够去存储当前的unxi时间戳。这个表现，被称为“LRU 时钟”，key元数据经常被更新，所以它是一个有效的算法。
然后，有另一个更加复杂的问题需要解决：如何选择访问间隔最长的key，然后淘汰它。
redis内部采用一个庞大的hash table来保存，添加另外一个数据结构存储时间间隔显然不是一个好的选择。然而我们希望能达到一个LRU本身是一个近似的，通过LRU算法本身来实现。

redis原始的淘汰算法简单实现：**当需要淘汰一个key时，随机选择3个key，淘汰其中间隔时间最长的key。**基本上，我们随机选择key，淘汰key效果很好。后来随机3个key改成一个配置项"N随机key"。但把默认值提高改成5个后效果大大提高。考虑到它的效果，你根本不用修改他。

然而，你可能会想这个算法如何有效执行，你可以看到我们如何捣毁了很多有趣的数据。也许简单的N key，我们会遇到很多好的决策，但是当我们淘汰最好的，下一个周期又开始抓。

验证规则第一条：用肉眼观察你的算法

其中有一个观点已经应用到Redis 3.0正式版中了。在redis2.8中一个LRU缓存经常被使用在多个环境，用户关于淘汰的没有抱怨太多，但是很明显我可以提高它，通过不仅仅是增加额外的空间，还有额外的CPU时间。
然而为了提高某项功能，你必须观察它。有多个不同的方式去观察LRU算法。你可以通过写工具观察，例如模拟不同的工作负载、校验命中率和失误率。
程序非常简单：增加一些指定的keys，然后频繁地访问这些keys以至于每一个key都有一个下降的空闲时间。最终超过50%的keys被增加，一半的老key需要被淘汰。
一个完美理想的LRU实现，应该是没有最新加的key被淘汰，而是淘汰最初的50%的老key。

规则二：不要丢弃重要信息

借助最新的可视化工具，我可以在尝试新的方法观察和测试几分钟。使用redis最明显有效的提高算法就是，积累对立的垃圾信息在一个淘汰池中。
基本上，当N keys算法被采用时，通常会分配一个很大的线程pool（默认为16key），这个池按照空闲时间排序，所以只有当有一个大于池中的一个或者池为空的时候，最新的key只会进入到这个池中。
同时，一个新的redis-cli模式去测量LRU算法也增加了(看这个-lru-test选项)。
还有另外一个方式去检验LRU算法的好坏，通过一个幂等访问模式。这个工具通常校验用一个不同的测试，新算法工作工作效果好于真实世界负载。它也同样使用流水线和每秒打印访问日志，因此可以被使用不用为了基准不同的思想，至少可以校验和观察明显的速度回归。

规则三、最少使用原则（LFU算法）

一切源于一个开放性问题：但你有多个redis 3.2数据库时，而淘汰算法只能在本机选择。因此，假如你全部空闲小的key都是DB0号机器，空闲时间长的key都是1号机器，redis每台机器都会淘汰各自的key。一个更好的选择当然是先淘汰DB1，最后再淘汰DB0。
当redis被当作缓存使用时很少有情况被分成不同的db上，这不是一个好的处理方式。然而这也是我为什么我再一次修改淘汰代码的原因。最终，我能够修改缓存池包括数据库id，使用单缓存池为多个db，代替多缓存池。这种实现很麻烦，但是通过优化和修改代码，最终它比普通实现要快到20%。
然而这时候，我对这个redis缓存淘汰算法的好奇心又被点燃。我想要提升它。我花费了几天想要提高LRU算法实现：或许可以使用更大的缓存池？通过历史时间选择最合适被淘汰的key？
经过一段时间，通过优化我的工具，我理解到：LRU算法受限于数据库中的数据样本，有时可能相反的场景效果非常好，因此要想提高非常非常难。实际上，能通过展示不同算法的图片上看这有点非常明显：每个周期10个keys几乎和理论的LRU算法表现一致。
当原始算法很难提高时，我开始测试新的算法。 如果我们倒回到博客开始，我们说过LRU实际上有点严格。哪些key需要我们真正想要保留：将来有最大可能被访问，最频繁被访问，而不是最近被访问的key。
淘汰最少被访问的key算法成为：LFU（Least Frequently Used），将来要被淘汰腾出新空间给新key。
理论上LFU的思想相当简单，只需要给每个key加一个访问计数器。每次访问就自增1，所以也就很容易知道哪些key被访问更频繁。
当然，LFU也会带起其他问题，不单单是针对redis，对于LFU实现：
1、不能使用“移除顶部元素”的方式，keys必须要根据访问计数器进行排序。每访问一次就得遍历所有key找出访问次数最少的key。
2、LFU不能仅仅是只增加每一访问的计数器。正如我们所讲的，访问模式改变随时变化，因此一个有高访问次数的key，后面很可能没有人继续访问它，因此我们的算法必须要适应超时的情况。
在redis中，第一个问题很好解决：我们可以在LRU的方式一样：随机在缓存池中选举，淘汰其中某项。第二个问题redis还是存在，因此一般对于LFU的思想必须使用一些方式进行减少，或者定期把访问计数器减半。

24位的LFU实现

LFU有它本身的实现，在redis中我们使用自己的24bit来记录LRU。
为了实现LFU仅仅需要在每个对象额外新增24bit：
1、一部分用于保存访问计数器；
2、足够用于决定什么时候将计数器减半的信息；

我的解决方法是把24bit分成两列：

16bits8bitslast decr timeLOG_C

16位记录最后一次减半时间，那样redis知道上一次减半时间，另外8bit作为访问计数器。
你可能会想8位的计数器很快就会溢出，是的，相对于简单计数器，我采用逻辑计数器。逻辑计数器的实现：

uint8_t LFULogIncr(uint8_t counter) {
      if (counter == 255) return 255;
      double r = (double)rand()/RAND_MAX;
      double baseval = counter - LFU_INIT_VAL;
      if (baseval < 0) baseval = 0;
      double p = 1.0/(baseval*server.lfu_log_factor+1);
      if (r < p) counter++;
      return counter;
  }

基本上计数器的较大者，更小的可能计数器会增加：上面的代码计算p位于0~1之间，但计数器增长时会越来越小，位于0-1的随机数r，只会但满足r<p时计数器才会加一。
你可以配置计数器增长的速率，如果使用默认配置，会发生：

• 100次访问后，计数器=10；
• 1000次访问是是18；
• 10万次访问是142；
• 100万次访问后达到255，并不在继续增长；

下面，让我们看看计数器如果进行衰减。16位的被储存为unix时间戳保留到分钟级别，redis会随机扫描key填充到缓存池中，如果最后一个下降的时间大于N分钟前（可配置化），如果计数器的值很大就减半，或者对于值小的就直接简单减半。
这里又衍生出另外一个问题，就是新进来的key是需要有机会被保留的。由于LFU新增是得分都是0，非常容易被选举替换掉。在redis中，开始默认值为5。这个初始值是根据增长数据和减半算法来估算的。模拟显示得分小于5的key是首选。

代码和性能

上面描述的算法已经提交到一个非稳定版的redis分支上。我最初的测试显示：它在幂等模式下优于LRU算法，测试情况是每个key使用用相同数量的内存，然而真实世界的访问可能会有很大不同。时间和空间都可能改变得很不同，所以我会很开心去学习观察现实世界中LFU的性能如何，两种方式在redis实现中对性能的改变。
因此，新增了一个OBJECT FREQ子命令，用于报告给定key的访问计数器，不仅仅能有效提观察一个计数器，而且还能调试LFU实现中的bug。
注意运行中切换LRU和LFU，刚开始会随机淘汰一些key，随着24bit不能匹配上，然而慢慢会适应。 还有几种改进实现的可能。Ben Manes发给我这篇感兴趣的文章，描述了一种叫TinyLRU算法。链接

这篇文章包含一个非常厉害的观点：相比于记录当前对象的访问频率，让我们（概率性地）记录全部对象的访问频率，看到了，这种方式我们甚至可以拒绝新key，同样，我们相信这些key很可能得到很少的访问，所以一点也不需要淘汰，如果淘汰一个key意味着降低命中/未命中率。
我的感觉这种技术虽然很感兴趣GET/SET LFU缓存，但不适用与redis性质的数据服务器：用户期望keys被创建后至少存在几毫秒。拒绝key的创建似乎在redis上就是一种错误。
然而，redis保留了LFU信息，当一个key被覆盖时，举个例子：

SET oldkey some_new_value

24位的LFU计数器会从老的key复制到新对象中。

新的redis淘汰算法不稳定版本还有以下几个好消息：
1、跨DB策略。在过去的redis只是基于本地的选举，现在修复为所有策略，不仅仅是LRU。
2、易变ttl策略。基于key预期淘汰存活时间，如今就像其他策略中的使用缓存池。
3、在缓存池中重用了sds对象，性能更好。

这篇博客比我预期要长，但是我希望它反映出一个见解：在创新和对于已经存在的事物实现上，一种解决方案去解决一个特定问题，一个基础工具。由开发人员以正确的方式使用它。许多redis的用户把redis作为一个缓存的解决方案，因此提高淘汰策略这一块经常一次又一次被拿出来探讨。