一、優(yōu)勢
（一）相對于其他k-v數(shù)據(jù)庫的優(yōu)勢
1. 包含復(fù)雜數(shù)據(jù)類型，例如Strings\Lists\Hashes\Sets\Sorted sets等。
這些復(fù)雜數(shù)據(jù)類型的操作提供了原子操作，不用考慮鎖。
2. 內(nèi)存中運(yùn)行；可以持久化。
3. 相關(guān)網(wǎng)站：
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
二、缺點(diǎn)
官方不支持windows版，有非官方的。這個(gè)不是太大問題。
三、性能
1. 內(nèi)存數(shù)據(jù)庫，性能非常高。
2. 與memcache的性能比較，redis作者給的回答，小數(shù)據(jù)的存儲redis占優(yōu)，大于100k的memcache占優(yōu)，但總的來說，一般項(xiàng)目使用時(shí)都還不夠格考慮這里的瓶頸。
四、使用者及口碑
暴雪、stackoverflow、github、flickr等等在使用redis。業(yè)內(nèi)口碑非常好。
http://redis.io/topics/whos-using-redis
五、結(jié)合我們項(xiàng)目使用
由于歷史原因，數(shù)據(jù)庫我們先后使用了兄弟公司的k-v數(shù)據(jù)庫，和之后的mysql。
換數(shù)據(jù)庫，是由于之前的k-v數(shù)據(jù)庫只支持key-value對的存儲，value里以json串來存儲。這樣的存儲方式不支持單個(gè)字段的更新以及高效的頻繁排序等功能算法需求。而游戲編程很需要這些，所以花大氣力彌補(bǔ)以前決策的失誤，DB換成了mysql。
項(xiàng)目架構(gòu)也在調(diào)整，php通過handlersocket與mysql進(jìn)行交互，之前的java只做簡單的同步，沒有db操作。現(xiàn)在為了性能考慮，在慢慢改成玩家頻繁交互的功能和部分別的新功能寫在java。這樣java就必須與db交互。
之前為了快速迭代，java與mysql的交互，是java通過http來post存儲請求到php，php接到request就立即存儲。php這邊有老php寫的邏輯更新了db字段時(shí)，再post一個(gè)request到j(luò)ava（java做了個(gè)http server），java更新自己的內(nèi)存。
這樣就有兩個(gè)問題。
1. 所有與db的操作，cache的地方在handlersocket；（據(jù)說有并發(fā)寫入性能問題——待進(jìn)一步考證）
2. php與java都要更新db數(shù)據(jù)時(shí)，兩個(gè)獨(dú)立的http通道，很詭異，很低效。
現(xiàn)在有了redis，pub/sub很方便做cache系統(tǒng)。
一方面php與java相互通知數(shù)據(jù)更新時(shí)，通過redis即可。目前我們先應(yīng)用急需的這塊。當(dāng)前項(xiàng)目php里使用memcache做交互臨時(shí)存儲以及部分用于加鎖的邏輯可以考慮用redis慢慢取代。
另一方面，以后可以很方便的用redis做我們應(yīng)用程序與mysql的cache。
ps：2012年12月20日我在CU的博客