为啥懒 Redis 是更好的 Redis
英文原文：LazyRedisisbetterRedis
前言
大家都知道Redis是单线程的。真正的内行会告诉你，实际上Redis并不是完全单线程，因为在执行磁盘上的特定慢操作时会有多线程。目前为止多线程操作绝大部分集中在I/O上以至于在不同线程执行异步任务的小型库被称为bio.c:也就是BackgroundI/O。
然而前阵子我提交了一个问题，在问题里我承诺提供一个很多人（包括我自己）都想要的功能，叫做“免费懒加载”。原始的问题在这
问题的根本在于，Redis的DEL操作通常是阻塞的。因此如果你发送Redis“DELmykey”命令，碰巧你的key有5000万个对象，那么服务器将会阻塞几秒钟，在此期间服务器不会处理其他请求。历史上这被当做Redis设计的副作用而被接受，但是在特定的用例下这是一个局限。DEL不是唯一的阻塞式命令，却是特殊的一个命令，因为我们认为：Redis非常快，只要你用复杂度为O(1)和O(log_N)的命令。你可以自由使用O(N)的命令，但是要知道这不是我们优化的用例，你需要做好延迟的准备。
这听起来很合理，但是同时即便用快速操作创建的对象也需要被删除。在这种情况下，Redis会阻塞。
第一次尝试
—
对于单线程服务器，为了让操作不阻塞，最简单的方式就是用增量的方式一点点来，而不是一下子把整个世界都搞定。例如，如果要释放一个百万级的对象，可以每一个毫秒释放1000个元素，而不是在一个for()循环里一次性全做完。CPU的耗时是差不多的，也许会稍微多一些，因为逻辑更多一些，但是从用户来看延时更少一些。当然也许实际上并没有每毫秒删除1000个元素，这只是个例子。重点是如何避免秒级的阻塞。在Redis内部做了很多事情：最显然易见的是LRU淘汰机制和key的过期，还有其他方面的，例如增量式的对hash表进行重排。
刚开始我们是这样尝试的：创建一个新的定时器函数，在里面实现淘汰机制。对象只是被添加到一个链表里，每次定时器调用的时候，会逐步的、增量式的去释放。这需要一些小技巧，例如，那些用哈希表实现的对象，会使用Redis的SCAN命令里相同的机制去增量式的释放：在字典里设置一个游标来遍历和释放元素。通过这种方式，在每次定时器调用的时候我们不需要释放整个哈希表。在重新进入定时器函数时，游标可以告诉我们上次释放到哪里了。
适配是困难的
—
你知道这里最困难的部分是哪里吗？这次我们是在增量式的做一件很特别的事情：释放内存。如果内存的释放是增量式的，服务器的内容增长将会非常快，最后为了得到更少的延时，会消耗调无限的内存。这很糟，想象一下，有下面的操作：
WHILE1
SADDmysetelement1element2…manymanymanyelements
DELmyset
END
如果慢慢的在后台去删除myset，同时SADD调用又在不断的添加大量的元素，内存使用量将会一直增长。
好在经过一段尝试之后，我找到一种可以工作的很好的方式。定时器函数里使用了两个想法来适应内存的压力：
1.检测内存趋势：增加还是减少？以决定释放的力度。
2.同时适配定时器的频率，避免在只有很少需要释放的时候去浪费CPU，不用频繁的去中断事件循环。当确实需要的时候，定时器也可以达到大约300HZ的频率。
这里有一小段代码，不过这个想法现在已经不再实现了：
/计算内存趋势，只要是上次和这次内存都在增加，就倾向于认为内存趋势 是增加的*/
if(prev_mem<mem)mem_trend=1;
mem_trend*=0.9;/*逐渐衰减*/
intmem_is_raising=mem_trend>.1;
/*释放一些元素*/
size_tworkdone=lazyfreeStep(LAZYFREE_STEP_SLOW);
/*根据现有状态调整定时器频率*/
if(workdone){
if(timer_period==1000)timer_period=20;
if(mem_is_raising&&timer_period>3)
timer_period--;/*Raisecallfrequency.*/
elseif(!mem_is_raising&&timer_period<20)
timer_period++;/*Lowercallfrequency.*/
}else{
timer_period=1000; /*1HZ*/
}
这是一个小技巧，工作的也很好。不过郁闷的是我们还是不得不在单线程里执行。要做好需要有很多的逻辑，而且当延迟释放（lazyfree）周期很繁忙的时候，每秒能完成的操作会降到平时的65%左右。
如果是在另一个线程去释放对象，那就简单多了：如果有一个线程只做释放操作的话，释放总是要比在数据集里添加数据来的要快。
当然，主线程和延迟释放线程直接对内存分配器的使用肯定会有竞争，不过Redis在内存分配上只用到一小部分时间，更多的时间用在I/O、命令分发、缓存失败等等。
不过，要实现线程化的延迟释放有一个大问题，那就是Redis自身。内部实现完全是追求对象的共享，最终都是些引用计数。干嘛不尽可能的共享呢？这样可以节省内存和时间。例如：SUNIONSTORE命令最后得到的是目标集合的共享对象。类似的，客户端的输出缓存包含了作为返回结果发送给socket的对象的列表，于是在类似SMEMBERS这样的命令调用之后，集合的所有成员都有可能最终在输出缓存里被共享。看上去对象共享是那么有效、漂亮、精彩，还特别酷。
但是，嘿，还需要再多说一句的是，如果在SUNIONSTORE命令之后重新加载了数据库，对象都取消了共享，内存也会突然回复到最初的状态。这可不太妙。接下来我们发送应答请求给客户端，会怎么样？当对象比较小时，我们实际上是把它们拼接成线性的缓存，要不然进行多次write()调用效率是不高的！（友情提示，writev()并没有帮助）。于是我们大部分情况下是已经复制了数据。对于编程来说，没有用的东西却存在，通常意味着是有问题的。
事实上，访问一个包含聚合类型数据的key，需要经过下面这些遍历过程：
key->value_obj->hashtable->robj->sds_string
如果去掉整个tobj结构体，把聚合类型转换成SDS字符串类型的哈希表（或者跳表）会怎么样？（SDS是Redis内部使用的字符串类型）。
这样做有个问题，假设有个命令：SADDmysetmyvalue，举个例子来说，我们做不到通过client->argv[2]来引用用来实现集合的哈希表的某个元素。我们不得不很多次的把值复制出来，即使数据已经在客户端命令解析后创建的参数vector里，也没办法去复用。Redis的性能受控于缓存失效，我们也许可以用稍微间接一些的办法来弥补一下。
于是我在这个lazyfree的分支上开始了一项工作，并且在Twitter上聊了一下，但是没有公布上下文的细节，结果所有的人都觉得我像是绝望或者疯狂了（甚至有人喊道lazyfree到底是什么玩意）。那么，我到底做了什么呢？
把客户端的输出缓存由robj结构体改成动态字符串。在创建reply的时候总是复制值的内容。
把所有的Redis数据类型转换成SDS字符串，而不是使用共享对象结构。听上去很简单？实际上这花费了数周的时间，涉及到大约800行高风险的代码修改。不过现在全都测试通过了。
把lazyfree重写成线程化的。
结果是Redis现在在内存使用上更加高效，因为在数据结构的实现上不再使用robj结构体（不过由于某些代码还涉及到大量的共享，所以robj依然存在，例如在命令分发和复制部分）。线程化的延迟释放工作的很好，比增量的方式更能减少内存的使用，虽然增量方式在实现上与线程化的方式相似，并且也没那么糟糕。现在，你可以删除一个巨大的key，性能损失可以忽略不计，这非常有用。不过，最有趣的事情是，在我测过的一些操作上，Redis现在都要更快一些。消除间接引用（Lessindirection）最后胜出，即使在不相关的一些测试上也更快一些，还是因为客户端的输出缓存现在更加简单和高效。
最后我把增量式的延迟释放实现从分支里删除，只保留了线程化的实现。
关于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分支。不过要注意的是，当前我并不是很频繁的更新这个分支，所以有些地方可能会不能工作。