Redis 或弃用当前 VM 机制，采用新的 diskstore 模型

Redis 的作者 Salvatore Sanfilippo（@antirez）今天在 Redis 的 Google Group 上发表了一篇文章，表明他对当前Redis 的VM机制并不满意，并称正在着手修改成一种新的实现逻辑。下面是主要内容的翻译。原文请看：http://goo.gl/uMKQN

　　要将数据持久化存储，大概考虑有这样三种方式：

1. 使用虚拟内存，即将冷数据放磁盘热并保存一份映射。（目前Redis使用的方式）
2. 将数据以内存映射的方式存磁盘，操作数据时直接操作磁盘，然后使用操作系统的Cache作为操作缓冲层。（作者称其为MongoDB的方式）
3. 将数据按自定义的格式存磁盘，但操作数据时并不直接操作磁盘，而是操作内存并在某种条件下将内存数据写到磁盘上。（作者打算使用的新方式）

　　当前VM的坏处：

1. slow restart 重启太慢
2. slow saving 保存数据太慢
3. slow replication 上面两条导致 replication 太慢
4. complex code 代码过于复杂

　　最后决定使用第三种方式，我们称这种实现为diskstore，下面是对diskstore的一些实现描述：

• 在diskstore实现中，我们把键值对存在磁盘上
• 内存中保存着热数据，数据的写操作全部记录在内存中，并不直接操作磁盘上的数据，所以磁盘数据可以按我们的方便进行排列。
• cache-max-memory 设置将会严格支持，就算我们设置这个值为2M而我们有10亿数据，内存使用也不会超过，之所以能做到这样，是因为我们连key值都不存在内存中。（是这意思么，为什么能做到这样？)
  如果有数据写操作存在的话，内存中的数据会被异步地flush到磁盘。
• 你可以控制从在内存中修改值到这个修改flush到磁盘的时间延迟，这样可能一个值在这段延迟的时间内被修改了多次但是只会写一次磁盘。
• 如果设置这个延迟为0的话，则会尽可能快地将写操作执行到磁盘上。
• 所有的磁盘IO操作都由一个专门的线程来执行，这个线程会一直执行不退出，这个线程由一个条件变量控制执行。
• datastore实现中，我们不用再考虑在存在有竞争条件下的undo操作，因此在实现上更简洁。
• 启动时间接近到0，几乎不需要任何加载操作。
• 在这个实现中，我们会实现一个不存在标记缓存，如果一个值在磁盘上不存在，那么在取这个值的时候我们会在内存中标记，那在再次取这个值的时候，我们就不用再去磁盘查看这个值是否在了。
• 如果我们的热数据和我们的内存大小差不多或者小于内存大小的话，那系统会非常快，但是如果热数据量比内存限制还大，那可能就会遭遇IO瓶颈了。这是无法避免的。
• 目前系统并不支持BGSAVE操作，但是即将会支持，我们可以想像，在diskstore的系统上实现BGSAVE将会中有很小的开销，因为我们的磁盘文件本来就是按照和.rdb文件一样的格式保存的，所以BGSAVE操作只需要复制数据文件就可以得到这个.rdb文件了。在复制文件的时候，内存中的写操作暂时会停止写到磁盘，所以系统在这个时候会把内存超出一点，但由于他不是写时复制，不会超出太多。（最后这个但是不太明白）
• 数据写入磁盘的持久化是操作是针对每个键来做的，所以并不存在某个时间点所有的数据都是持久化到磁盘中的。