redis为什么不使用btree而是使用skiplist

原作者回复:

There are a few reasons:

1) They are not very memory intensive. It's up to you basically. Changing parameters about the probability of a node to have a given number of levels will make thenless memory intensive than btrees.

2) A sorted set is often target of many ZRANGE or ZREVRANGE operations, that is, traversing the skip list as a linked list. With this operation the cache locality of skip lists is at least as good as with other kind of balanced trees.

3) They are simpler to implement, debug, and so forth. For instance thanks to the skip list simplicity I received a patch (already in Redis master) with augmented skip lists implementing ZRANK in O(log(N)). It required little changes to the code.

About the Append Only durability & speed, I don't think it is a good idea to optimize Redis at cost of more code and more complexity for a use case that IMHO should be rare for the Redis target (fsync() at every command). Almost no one is using this feature even with ACID SQL databases, as the performance hint is big anyway.

About threads: our experience shows that Redis is mostly I/O bound. I'm using threads to serve things from Virtual Memory. The long term solution to exploit all the cores, assuming your link is so fast that you can saturate a single core, is running multiple instances of Redis (no locks, almost fully scalable linearly with number of cores), and using the "Redis Cluster" solution that I plan to develop in the future. 

总的来说，就是

1.占用更少的内存

2. 更容易实现，代码量少

3. 以及在对ZRANGE之类的查询更快

 

题外话:

btree和红黑树都是比较复杂的数据结构，而且其实对内存很不友好 。

redis里面list很多都是ziplist，其实就是一个数组，对于内存的cache很友好，这里涉及到CPU的缓存问题。只要知道访问一段连续的内存比一段破碎的内存速度更快就可以了