分析redis的几个问题：
1，redis的“脏快照”
redis的持久化方式是后台线程慢慢写，则在写的过程中，如果外界进行了set，则redis写下的数据并不是一个干净的快照，而是一份数据可能不匹配的“脏快照”。
举例来说：在SNS里面，AB各有10分，然后A扣了5分给B，，则A应该5分B应该15分，但是在redis的脏快照里面，可能是A5分B10分，总数不对。
不要认为分数不重要，sns的用户整天就盯着分数看，分数不对的话，客服的电话会被打爆的。
2，redis的启动速度
很明显，redis重启的时候需要读取那些快照，这肯定影响启动速度。
3，网络或者机器损坏的时候，redis的快照并不能发挥作用
我们的高可用性设计很大程度上是为了防止网络或者机器硬件异常，这是常见的，因为机房里面经常会有路由调整什么的。
4，redis提供的更多编辑功能可能会带来麻烦
为了保证没有“脏数据”，缓存的正确使用方式应该是：只用delete和set方法，以保证在其他模块写失败（比如db的transaction rollback）的时候，可以在缓存进行重复的操作，而不会出现错误数据。换句话说，为了保证数据正确性，即使是memcached的prepend/append、inc/dec都应该避免使用，则list、mapset这些高级数据结构将遇到更严格的限制。
不注意这点的话，缓存里面的脏数据在未来的某些时候将让你痛不欲生。
5，redis号称比memcached速度更快，但是我看到很多反面数据
memcached速度更快的测试结果，比如：http://systoilet.wordpress.com/2010/08/09/redis-vs-memcached/
不要完全相信redis的测试数据，比如：http://antirez.com/post/redis-memcached-benchmark.html
因为memcached每秒可以处理20w以上的请求：http://code.google.com/p/memcached/wiki/NewPerformance
我相信memcached的数据，因为我知道长连接的时候单线程每秒钟处理6w个http请求是可能的，那么每秒处理20w个kv请求完全是一个合理的数字。则redis的测试数字多半是不严谨的。
结论
redis是一个nosql，竞争对手是casandra, membase, mongodb之类的其他nosql数据库。
redis和memcached不是同一种东西。
补充
github是redis重点宣传的用户，让我们看看github是怎么使用redis的：https://github.com/blog/530-how-we-made-github-fast，注意中间：在介绍完redis的使用之后有段话“The above flow is what happens when there are no cache hits.”，然后是“In many cases the Rails code uses Evan Weaver’s Ruby memcached client to query the Memcache servers that run on each slave file server.”，真相大白了，github到底还是在用memcached作缓存的。
另一个使用redis的著名网站stackoverflow倒是在用redis当cache layer，但是让我们看看性能数字“Around peak time we're getting a few hundred read/writes a second to Redis”，就这点流量，其实用打孔机或者磁带机当cache layer也足够的。
再然后就是新浪了，据说新浪微博是用了redis的，但我知道新浪用redis时遇到一堆问题，然后他们自己改了不少。参见：http://www.slideshare.net/mysqlops/redis-9806617，你看他们遇到的高延迟、高内存、cpu瓶颈、fork、磁盘瓶颈，这一堆的问题，其实都是没必要遇到的问题。然后有分析文章指出，新浪微博的redis其实还是和mysql一起使用，干嘛不直接用memcached？