ledisDB底层实现——本质上就是用leveldb这样的底层存储，和ssdb一样，meta里存的是hash、list等的元数据

List

list只支持从两端push，pop数据，而不支持中间的insert，这样主要是为了简单。我们使用key:sequence的方式来存放list实际的值。 sequence是一个int整形，一个list最多存放1<<31 - 2000条数据，至于为啥是1000，我说随便定得你信不？ 对于一个list来说，我们会记录head seq以及tail seq，用来获取当前list开头和结尾的数据。 当第一次push一个list的时候，我们将head seq以及tail seq都设置为listInitialSeq。当lpush一个value的时候，我们会获取当前的head seq，然后将其减1，新得到的head seq存放对应的value。而对于rpush，则是tail seq + 1。 当lpop的时候，我们会获取当前的head seq，然后将其加1，同时删除以前head seq对应的值。而对于rpop，则是tail seq - 1。 我们在list里面一个meta key来存放该list对应的head seq，tail seq以及size信息。

ZSet

zset可以算是最为复杂的，我们需要使用三套key来实现。需要用一个key来存储zset的size，需要用一个key:member来存储对应的score，需要用一个key:score:member来实现按照score的排序。

这里重点说一下score，在redis里面，score是一个double类型的，但是我们决定在ledisdb里面只使用int64类型，原因一是double还是有浮点精度问题，在不同机器上面可能会有误差（没准是我想多了），另一个则是我不确定double的8字节memcmp是不是也跟实际比较结果一样（没准也是我想多了），其实更可能的原因在于我们觉得int64就够用了，实际上我们项目也只使用了int的score。 因为score是int64的，我们需要将其转成大端序存储（好吧，我假设大家都是小端序的机器），这样通过memcmp比较才会有正确的结果。同时int64有正负的区别，负数最高位为1，所以如果只是单纯的进行binary比较，那么负数一定比正数大，这个我们通过在构建key的时候负数前面加"<"，而正数（包括0）加"="来解决。所以我们score这套key的格式就是这样： key<score:member //<0key=score:member //>=0 对于zset的range处理，其实就是确定某一个区间之后通过leveldb iterator进行遍历获取，这里我们需要明确知道的事情是leveldb的iterator正向遍历的速度和逆向遍历的速度完全不在一个数量级上面，正向遍历快太多了，所以最好别去使用zset里面带有rev前缀的函数。

总结

总的来说，用leveldb来实现redis那些高级的数据结构还算是比较简单的，同时根据我们的压力测试，发现性能还能接受，除了zset的rev相关函数，其余的都能够跟redis保持在同一个数量级上面，具体可以参考ledisdb里面的性能测试报告以及运行ledis-benchmark自己测试。 后续ledisdb还会持续进行性能优化，同时提供expire以及replication功能的支持，预计6月份我们就会实现。 ledisdb的代码在这里https://github.com/siddontang/ledisdb，希望感兴趣的童鞋共同参与。

摘自：http://www.itkeyword.com/doc/0652992288452803948

ledisDB底层实现——本质上就是用leveldb这样的底层存储，和ssdb一样，meta里存的是hash、list等的元数据

标签：参与   chm   sid   数量级   evel   led   小端   ber   处理