英文原文：Lazy Redis is better Redis

前言

大家都知道 Redis 是单线程的。真正的内行会告诉你，实际上 Redis 并不是完全单线程，因为在执行磁盘上的特定慢操作时会有多线程。目前为止多线程操作绝大部分集中在 I/O 上以至于在不同线程执行异步任务的小型库被称为 bio.c: 也就是 Background I/O。

然而前阵子我提交了一个问题，在问题里我承诺提供一个很多人（包括我自己）都想要的功能，叫做“免费懒加载”。原始的问题在这

问题的根本在于，Redis 的 DEL 操作通常是阻塞的。因此如果你发送 Redis “DEL mykey” 命令，碰巧你的 key 有 5000万个对象，那么服务器将会阻塞几秒钟，在此期间服务器不会处理其他请求。历史上这被当做 Redis 设计的副作用而被接受，但是在特定的用例下这是一个局限。DEL 不是唯一的阻塞式命令，却是特殊的一个命令，因为我们认为：Redis 非常快，只要你用复杂度为 O(1) 和 O(log_N) 的命令。你可以自由使用 O(N) 的命令，但是要知道这不是我们优化的用例，你需要做好延迟的准备。

这听起来很合理，但是同时即便用快速操作创建的对象也需要被删除。在这种情况下，Redis 会阻塞。

第一次尝试
—

对于单线程服务器，为了让操作不阻塞，最简单的方式就是用增量的方式一点点来，而不是一下子把整个世界都搞定。例如，如果要释放一个百万级的对象，可以每一个毫秒释放1000个元素，而不是在一个 for() 循环里一次性全做完。CPU 的耗时是差不多的，也许会稍微多一些，因为逻辑更多一些，但是从用户来看延时更少一些。当然也许实际上并没有每毫秒删除1000个元素，这只是个例子。重点是如何避免秒级的阻塞。在 Redis 内部做了很多事情：最显然易见的是 LRU 淘汰机制和 key 的过期，还有其他方面的，例如增量式的对 hash 表进行重排。

刚开始我们是这样尝试的：创建一个新的定时器函数，在里面实现淘汰机制。对象只是被添加到一个链表里，每次定时器调用的时候，会逐步的、增量式的去释放。这需要一些小技巧，例如，那些用哈希表实现的对象，会使用 Redis 的 SCAN 命令里相同的机制去增量式的释放：在字典里设置一个游标来遍历和释放元素。通过这种方式，在每次定时器调用的时候我们不需要释放整个哈希表。在重新进入定时器函数时，游标可以告诉我们上次释放到哪里了。

适配是困难的
—

你知道这里最困难的部分是哪里吗？这次我们是在增量式的做一件很特别的事情：释放内存。如果内存的释放是增量式的，服务器的内容增长将会非常快，最后为了得到更少的延时，会消耗调无限的内存。这很糟，想象一下，有下面的操作：

WHILE 1
    SADD myset element1 element2 … many many many elements
    DEL myset
END

如果慢慢的在后台去删除myset，同时SADD调用又在不断的添加大量的元素，内存使用量将会一直增长。

好在经过一段尝试之后，我找到一种可以工作的很好的方式。定时器函数里使用了两个想法来适应内存的压力：

1.检测内存趋势：增加还是减少？以决定释放的力度。

2.同时适配定时器的频率，避免在只有很少需要释放的时候去浪费CPU，不用频繁的去中断事件循环。当确实需要的时候，定时器也可以达到大约300HZ的频率。
这里有一小段代码，不过这个想法现在已经不再实现了：

/计算内存趋势，只要是上次和这次内存都在增加，就倾向于认为内存趋势
 是增加的 */

if (prev_mem < mem) mem_trend = 1;
   
mem_trend *= 0.9; /* 逐渐衰减 */
   
int mem_is_raising = mem_trend > .1;

   
/* 释放一些元素 */
   
size_t workdone = lazyfreeStep(LAZYFREE_STEP_SLOW);

   
/* 根据现有状态调整定时器频率 */
   
if (workdone) {
       
    if (timer_period == 1000) timer_period = 20;

    if (mem_is_raising && timer_period > 3)
           
        timer_period--; /* Raise call frequency. */
       
    else if (!mem_is_raising && timer_period < 20)

        timer_period++; /* Lower call frequency. */
   
} else {
       
  timer_period = 1000;    /* 1 HZ */
   
}

这是一个小技巧，工作的也很好。不过郁闷的是我们还是不得不在单线程里执行。要做好需要有很多的逻辑，而且当延迟释放（lazy free）周期很繁忙的时候，每秒能完成的操作会降到平时的65%左右。
如果是在另一个线程去释放对象，那就简单多了：如果有一个线程只做释放操作的话，释放总是要比在数据集里添加数据来的要快。

当然，主线程和延迟释放线程直接对内存分配器的使用肯定会有竞争，不过 Redis 在内存分配上只用到一小部分时间，更多的时间用在I/O、命令分发、缓存失败等等。
不过，要实现线程化的延迟释放有一个大问题，那就是 Redis 自身。内部实现完全是追求对象的共享，最终都是些引用计数。干嘛不尽可能的共享呢？这样可以节省内存和时间。例如：SUNIONSTORE 命令最后得到的是目标集合的共享对象。类似的，客户端的输出缓存包含了作为返回结果发送给socket的对象的列表，于是在类似 SMEMBERS 这样的命令调用之后，集合的所有成员都有可能最终在输出缓存里被共享。看上去对象共享是那么有效、漂亮、精彩，还特别酷。

但是，嘿，还需要再多说一句的是，如果在 SUNIONSTORE 命令之后重新加载了数据库，对象都取消了共享，内存也会突然回复到最初的状态。这可不太妙。接下来我们发送应答请求给客户端，会怎么样？当对象比较小时，我们实际上是把它们拼接成线性的缓存，要不然进行多次 write() 调用效率是不高的！（友情提示，writev() 并没有帮助）。于是我们大部分情况下是已经复制了数据。对于编程来说，没有用的东西却存在，通常意味着是有问题的。
事实上，访问一个包含聚合类型数据的key，需要经过下面这些遍历过程：

key -> value_obj -> hash table -> robj -> sds_string

如果去掉整个 tobj 结构体，把聚合类型转换成 SDS 字符串类型的哈希表（或者跳表）会怎么样？（SDS是Redis内部使用的字符串类型）。

这样做有个问题，假设有个命令：SADD myset myvalue，举个例子来说，我们做不到通过client->argv[2] 来引用用来实现集合的哈希表的某个元素。我们不得不很多次的把值复制出来，即使数据已经在客户端命令解析后创建的参数 vector 里，也没办法去复用。Redis的性能受控于缓存失效，我们也许可以用稍微间接一些的办法来弥补一下。
于是我在这个 lazyfree 的分支上开始了一项工作，并且在 Twitter 上聊了一下，但是没有公布上下文的细节，结果所有的人都觉得我像是绝望或者疯狂了（甚至有人喊道 lazyfree 到底是什么玩意）。那么，我到底做了什么呢？

把客户端的输出缓存由 robj 结构体改成动态字符串。在创建 reply 的时候总是复制值的内容。
把所有的 Redis 数据类型转换成 SDS 字符串，而不是使用共享对象结构。听上去很简单？实际上这花费了数周的时间，涉及到大约800行高风险的代码修改。不过现在全都测试通过了。
把 lazyfree 重写成线程化的。
结果是 Redis 现在在内存使用上更加高效，因为在数据结构的实现上不再使用 robj 结构体（不过由于某些代码还涉及到大量的共享，所以 robj 依然存在，例如在命令分发和复制部分）。线程化的延迟释放工作的很好，比增量的方式更能减少内存的使用，虽然增量方式在实现上与线程化的方式相似，并且也没那么糟糕。现在，你可以删除一个巨大的 key，性能损失可以忽略不计，这非常有用。不过，最有趣的事情是，在我测过的一些操作上，Redis 现在都要更快一些。消除间接引用（Less indirection）最后胜出，即使在不相关的一些测试上也更快一些，还是因为客户端的输出缓存现在更加简单和高效。

最后我把增量式的延迟释放实现从分支里删除，只保留了线程化的实现。

关于 API 的一点备注

不过 API 又怎么样了呢？DEL 命令仍然是阻塞的，默认还跟以前一样，因为在 Redis 中 DEL 命令就意味着释放内存，我并不打算改变这一点。所以现在你可以用新的命令 UNLINK，这个命令更清晰的表明了数据的状态。

UNLINK 是一个聪明的命令：它会计算释放对象的开销，如果开销很小，就会直接按 DEL 做的那样立即释放对象，否则对象会被放到后台队列里进行处理。除此之外，这两个命令在语义上是相同的。

我们也实现了 FLUSHALL/FLUSHDB 的非阻塞版本，不过没有新增的 API，而是增加了一个 LAZY 选项，说明是否更改命令的行为。

不只是延迟释放

—

现在聚合数据类型的值都不再共享了，客户端的输出缓存也不再包含共享对象了，这一点有很多文章可做。例如，现在终于可以在 Redis 里实现线程化的 I/O，从而不同的客户端可以由不同的线程去服务。也就是说，只有访问数据库才需要全局的锁，客户端的读写系统调用，甚至是客户端发送的命令的解析，都可以在线程中去处理。这跟 memcached 的设计理念类似，我比较期待能够被实现和测试。

还有，现在也可以在其他线程实现针对聚合数据类型的特定的慢操作，可以让某些 key 被“阻塞”，但是所有其他的客户端不会被阻塞。这个可以用很类似现在的阻塞操作的方式去完成（参考blocking.c），只是增加一个哈希表保存那些正在处理的 key 和对应的客户端。于是一个客户端请求类似 SMEMBERS 这样的命令，可能只是仅仅阻塞住这一个 key，然后会创建输出缓存处理数据，之后在释放这个 key。只有那些尝试访问相同的 key 的客户端，才会在这个 key 被阻塞的时候被阻塞住。
所有这些需求起了更激烈的内部变化，但这里的底线我们已很少顾忌。我们可以补偿对象复制时间来减少高速缓存的缺失，以更小的内存占用聚合数据类型，所以我们现在可依照线程化的 Redis 来进行无共享化设计，这一设计，可以很容易超越我们的单线程。在过去，一个线程化的 Redis 看起来总像是一个坏主意，因为为了实现并发访问数据结构和对象其必定是一组互斥锁，但幸运的是还有别的选择获得这两个环境的优势。如果我们想要，我们依然可以选择快速操作服务，就像我们过去在主线程所做的那样。这包含在复杂的代价之上，获取执行智能（performance-wise）。

计划表
—

我在内部增加了很多东西，明天就上线看上去是不现实的。我的计划是先让3.2版（已经是unstable状态）成为候选版本（RC）状态，然后把我们的分支合并到进入unstable的3.4版本。

不过在合并之前，需要对速度做细致的回归测试，这有不少工作要做。

如果你现在就想尝试的话，可以从Github上下载lazyfree分支。不过要注意的是，当前我并不是很频繁的更新这个分支，所以有些地方可能会不能工作。