Redis与Memcached

　　总结一下：

　　1) Redis其实只适合作为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合当作一个普通功能来用。对于这个版本的Redis，不建议使用任何的持久化方式。否则到时候可能会死的比较难看。说白了，期望Redis是memcached的升级版，带有各种数据结构，但是不要期望Redis来和Mongodb/Kt等来比。

　　2) 对于VM其实也是不建议开启，虽然开启VM可以让Redis保存比内存更多的数据，但是如果冷热数据不是很明显的话性能会非常差(我的测试都是随机查询Key，冷热不明显)。当然，对于冷热明显的情况下可以设置200% - 400%的内存作为VM空间，也不建议设置10倍的内存空间作为VM(像我的配置一样)。

　　3) ServiceStack.Redis客户端好像有几个Bug，首先RedisTypedClient的Dispose居然没有实现，应该是要调用client.Dispose()，其次RedisNativeClient的Info属性不是每次都获取最新值的，第三PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加没看到减的地方，也不知道这是干啥的，其实每次都取第一个不是Active的Client就可以了，PooledRedisClientManager也没有把超时使用的Active的Client强制回收(避免使用的时候忘记Dispose占用过多的连接)。有关这几点，我会尝试联系ServiceStack.Redis的作者。

• 没有必要过于关注性能，因为二者的性能都已经足够高了。由于Redis只使用单核，而Memcached可以使用多核，所以二者比较起来，平均每一个核上，Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis。虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。说了这么多，结论是，无论你使用哪一个，每秒处理请求的次数都不会成为瓶颈。
• 在内存使用效率上，如果使用简单的key-value存储，Memcached的内存利用率更高。而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。
• 如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis。因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。
• 当然，最后还得说到你的具体应用需求。Redis相比Memcached来说，拥有更多的数据结构，并支持更丰富的数据操作。通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果你需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。