一、优势
（一）相对于其他k-v数据库的优势
1. 包含复杂数据类型，例如Strings\Lists\Hashes\Sets\Sorted sets等。
这些复杂数据类型的操作提供了原子操作，不用考虑锁。
2. 内存中运行；可以持久化。
3. 相关网站：
http://redis.io/
http://www.slideshare.net/hitkidnil/memcached-vs-redis
http://www.itlearner.com/article/4890
http://timyang.net/data/redis-misunderstanding/
http://stackoverflow.com/questions/2873249/is-memcached-a-dinosaur-in-comparison-to-redis
二、缺点
官方不支持windows版，有非官方的。这个不是太大问题。
三、性能
1. 内存数据库，性能非常高。
2. 与memcache的性能比较，redis作者给的回答，小数据的存储redis占优，大于100k的memcache占优，但总的来说，一般项目使用时都还不够格考虑这里的瓶颈。
四、使用者及口碑
暴雪、stackoverflow、github、flickr等等在使用redis。业内口碑非常好。
http://redis.io/topics/whos-using-redis
五、结合我们项目使用
由于历史原因，数据库我们先后使用了兄弟公司的k-v数据库，和之后的mysql。
换数据库，是由于之前的k-v数据库只支持key-value对的存储，value里以json串来存储。这样的存储方式不支持单个字段的更新以及高效的频繁排序等功能算法需求。而游戏编程很需要这些，所以花大气力弥补以前决策的失误，DB换成了mysql。
项目架构也在调整，php通过handlersocket与mysql进行交互，之前的java只做简单的同步，没有db操作。现在为了性能考虑，在慢慢改成玩家频繁交互的功能和部分别的新功能写在java。这样java就必须与db交互。
之前为了快速迭代，java与mysql的交互，是java通过http来post存储请求到php，php接到request就立即存储。php这边有老php写的逻辑更新了db字段时，再post一个request到java（java做了个http server），java更新自己的内存。
这样就有两个问题。
1. 所有与db的操作，cache的地方在handlersocket；（据说有并发写入性能问题——待进一步考证）
2. php与java都要更新db数据时，两个独立的http通道，很诡异，很低效。
现在有了redis，pub/sub很方便做cache系统。
一方面php与java相互通知数据更新时，通过redis即可。目前我们先应用急需的这块。当前项目php里使用memcache做交互临时存储以及部分用于加锁的逻辑可以考虑用redis慢慢取代。
另一方面，以后可以很方便的用redis做我们应用程序与mysql的cache。
ps：2012年12月20日我在CU的博客