Redis灵活的配置允许我们做各种优化，并且也提供了尽可能灵活和丰富的API。从效率上来说，我做过简单的性能测试，比memcached有略微高一点的读写效率(比libevent更轻量级的网络实现?)，但是在快照方式持久化的时候，读写效率一下子降低，可能大量的IO都用于内存映像的转存了，CPU占用也很高。在达到500万数据量之后，读写效率可以降低一半。

　　另外要说明的是，每一个Redis的API都提供了Big O表示法，在使用之前需要了解，您不能期待双向链表的随机读取效率和hashtable的随机读取效率一样。

　　换一句话说，我们需要细致得去使用Redis，尽量确保比较少的大O，尽量确保比较少的网络传输，不能像使用关系型数据库一样。

　　现在再来说说另外一个问题，那就是集群/数据分区。对于memcached这样的缓存来说，一致性哈希就可以了，我们只需要保证在扩容的时候不会损失大量的命中，并不一定要保证数据不能丢失。在业务系统重启的时候，缓存数据往往也需要重新来过，因此memcached服务端并没有实现集群，这一切都是客户端进行的。对于存储就不一样了，比如mongodb实现了sharding，而如果现在希望把Redis用作存储并且一个节点不足以支持应用的话，我们可以手动为业务分配不同的节点，也可以和memcached一样采取一致性哈希(在扩容的时候业务上可以忍受部分数据的丢失，Redis现在还没有支持客户端哈希的.NET客户端)。

　　对于Redis 3.0，据说会支持Redis集群：

　　1) 节点之间可以互相通讯，和服务端口不同的端口通讯。

　　2) 所有数据的key被分成几千份(哈希槽)，分布在现有的节点中。

　　3) 在增加了一个节点后，会把相应的数据转移过去。

　　4) 新的key的操作会转移到新节点，老的key的操作每一次都会询问老节点是否已转移。

　　5) 转移完成之后所有之后的请求会直接请求新的节点。

　　6) 节点支持主从多份备份，自动适应节点的故障(和mongodb的replica set类似)。

　　据说这都会在服务端实现，也就是proxy方式，那么到时候可能会有config/proxy/data不同形式的节点(和mongodb的sharding类似)。

　　其实如果能不根据key的数量而根据key的访问压力进行迁移的话那就更好了，不过这样config db可能需要存储更多的数据。

　　总而言之，Redis创新点是很多的，使用起来也是很灵活的，当然也就意味着配置和API的复杂。完全可以使用Redis完整实现一个应用。

　　Mongodb实现超大日志/报表数据存储，Redis实现部分业务数据的计算和缓存/存储，配合起来确实不错。

　　感叹一下，开源的东西变化快，BUG修改快，客户端比较悲剧，不断需要和服务端保持同步的修改。