2.1   ADT服务器

该文章主要讨论的是key-value类型的内存数据库

在内存数据库的设计中，有两种思路：

1. 将任意数据序列化后存储在内存中，数据库不了解保存的内容类型

2. 将特定类型的数据用既定的接口存储在内存中，数据库了解保存的

   内容的类型，并能对其做精细化的控制

第一种方式的典型代表是memcached, 而第二种方式的典型代表则是redis

这里我们主要讨论第二种方式。

3.1   redis是什么

以下摘录来自redis官方的描述文档:

Redis is an open source, advanced key-value store.
It is often referred to as a data structure server
since keys can contain strings, hashes, lists,
sets and sorted sets.

注意，它也认可自身是一个数据结构服务器的说法

3.2   redis有什么特性

1. 服务器提供多种数据类型，string, list, set, hash, sorted set，

   并且根据每种类型提供相应的操作方法，例如对于sorted set类型，

   就有获取某些区间内值的操作方法，这个对于典型的web列表分页是

   非常有帮助的

2. 服务器的数据类型是抽象的，比如hash类型，自从2.2以后，对于小数据量

   的hash类型，使用的是一种优化过的叫做zipmap的存储，而大于一定数量

   以后，则切换到另外一种存储，（由此引发了切换攻击，:]）。这一点

   是很便利的，用户得到了使用上的便利与存储上的便宜。

3.3   redis有什么问题

1, 设计一个命令叫 PLUS, 他只有固定两个参数，一个是定位器，一个是值

2, 定位标记可以规定，#开头的为hash类型, $开头的为字符类型，.(点)作为分隔符

    因此必须相应的禁止redis的key中使用特殊符号如# $ . 之类，这不是问题

3，根据1和2的规定 原来的 INCRBY str_key 1 命令可以改为 PLUS $str_key 1

   而 HINCRBY hkey field 1 则可以改为 PLUS #hkey.field 1

4，该方法还可以进一步套到 sorted set上去。

3.4   redis官方的补救

官方也意识到了一些问题，可能没我想得那么多，所以2.6以后带了lua script，原来只

是个分支，但是antire已经弄到主版本了，但问题在于lua虽然跟python ruby比是个小巧

的语言，但是在redis这种应用场景里，就算是个大语言了，lua核心也谈不上最小，

iolanguage就号称vm比lua的小多了。关键还不在于此，lua为着通用目的考虑，给语言加

了一些特性，这些是定制化无法删除的，你总不能把那套meta table的机制删掉吧？该类

脚本一出手，可能自身的语言机制消耗的性能要比完成的逻辑消耗的性能大多了，lua本

来就是面向table的，如果真的性能比redis的hash高，那就完全可以自己做个redis

server的角色了，我以前写的饭否爬虫就是用lua的table在内存里缓存了200k的用户信息

用起来就跟redis的hash一样的。

当然官方还无意识的提供了另外的有一些补救，比如由于是c写的，代码组织上又比较友

好，所以实际上你当然可以根据自己的特殊需求来定制一些数据类型，例如前面提到的

支持多个排序依据的sorted set，但是阿，这解决不了所有问题哥哥，如果你想在hash里

的一个field里再存一个hash，并且要跟系统的实现一致，你怎么办呢？ 如果你是自己实

现了一个 naked hash 选定调用了官方的一个实现，那么如果有另外一个人也实现了一套

hash，你是否又要改代码以便在某些条件下去调用他的实现函数呢？ 所以说这是个泥淖

任谁走进来，过一阵都会陷下去无法自拔了。

3.5   我的总结

redis 相比 memcache是开启了一种使用内存的新方式，这个开创性的举动当然是值

得赞扬的，但是一旦现在大家都加入进来，大规模使用以后，是可以发现其中存在的许多

问题的，例如 redis比memcache多的就是数据类型，但自己数据类型不够怎么办? 还有

策略不灵活，以前只是把memcache当缓存用，这个问题无足轻重，现在有的已经当作主要

数据库用了，那么这个问题就很重要了，再有就是命令设计的不够规范，或者再具体点，

不够正交，基本上是需要一个功能就多个命令，而不是从全盘考虑是否需要增加新命令

还是修改已有命令的实现。这个有点类似处理器分类中的 CISC 类型。像那个INCRBY与

HINCRBY两个命令的存在就好像x86里有这种寻址那种寻址N多种寻址一样。

4.1   虚拟机

就像前面提到的那样，redis目前就像是CISC cpu, 有一个功能就加一个指令，这个

颇有点头疼医头，脚疼医脚，既然谈到CISC，那么不得不提到RISC，RISC对于CISC的改进

可以看得到的就是简化指令，这个大家可以参考下intel的x86指令集砖头书与mips的

mips32指令集的示意图，两者的差别应该是很明显的，如我先前所提到的那样，INCRBY

与HINCRBY 完全可以设计成一个指令，只是得配合另外一个定位功能，所以就像RISC虽然

精简了指令集数目，但往往实现同样一个功能会增加几个指令一样，我之前自己设计的

PLUS指令可能就会相对INCRBY和HINCRBY要多出一些判断数据类型以及多重定位的处理步

骤，这一点就我个人来说，是可以接受的。

另外的问题是策略不够灵活，我之前说过你完全可以自己定制类型实现，但如果是

嵌套的类型就比较难办，你得能够调用其他人写的实现，如果你不了解内在的实现，就c

语言来说就无法动态的调用相应的实现，也许函数指针是可以的，但你得定个调用规范，

类似FFI那样麻烦，这种情况下，不如使用分离式的设计，既将redis server分离为虚拟

机与存储器实现两个部分，虚拟机指令集应该由官方控制，但是预留客户定制的指令空间

至于存储器实现那就可以官方只实现经典的那些，而客户可以自行根据自己的策略实现某

种符合官方定义的数据类型，例如带SSD备份的hash类型，而list仍然只用在内存里的方

式，掉电不管。

这里的好处在于，通过分离式的设计，达到了策略上的完全灵活，一个命令，你既可

以带检查，也可以直接映射某个存储类型提供的操作，这一切取决于你的程序，相比较

redis2.6提供的lua方案，这个虚拟机的开销要远比起个lua其语言的开销小多了。另外

这个方案的好处还在于提供升级与降级的简易方案，写过虚拟机的朋友都晓得，移植cpu

远比移植一个完整应用容易，因为cpu就那几个指令，像我的tweezervm那更是精简得吓人

因为是堆栈式的，只有30来个指令，c/py的版本都能轻松实现，当然，其实你也可以用

fpga烧录一个专用的cpu,这个相比你的汇编实现的redis还给力哦。何况，必要时候你可

以轻松切换到jvm上去 ：] 考虑到最近facebook正在往jvm上迁，企业用户应该更喜欢这

个方案吧。

4.2   ADT

ADT就是抽象数据类型的意思，学过c的应该有所了解，我虽然半路出家，恰好也在

云风那学到了这口黑话。ADT的好处在于你可以依据策略来调整实现，但行为的效果却是

对外一致的。这种方式，当然是很适合虚拟机这种设计的，因为你如果用c的宏 那只是在

编译时候就确定的了，在你运行时就糟糕了。另外核心的逻辑代码能够大大的精简，我看

c代码有大量的宏判断，为相关的调用做数据准备之类的冗余，核心逻辑往往就隐藏在这

一堆里，十分影响后来的人理解系统

4.3   具体的工程方案

我是个开发工程师而不是CS理论科学家，所以我能够给出一些工程上的实践方案，由

于ADT的部分实在是很简单，而且具体的工程方法与策略有关，我当然无法给出什么具体

的建议，因此我着重针对虚拟机的设计给出一些建议

4.4   我的方案的一些问题

1. 代码品质问题，有可能某些恶劣的实现拖累了整体的运行速度，或者是某些实现

   会泄漏内存，额。

2. 多种实现的冲突问题，比如两个插件都强调写硬盘，由于互相争抢，反而有可能

   导致双方的效率都低下从而无法达到预期的效果

3. 开发者的预期可能和具体的实现不一致，不过我觉得出现这种问题，多半是那种

   开发与运维有隔阂的大公司，小团队应该问题不大。