使用場景：

一祭刚、如果需要緩存的數(shù)據(jù)只是key-value 這樣簡單的結(jié)構(gòu)時牌捷，采用Memcache，足夠穩(wěn)定可靠袁梗。如果有持久化需求宜鸯、存儲、排序等一系列復(fù)制操作時遮怜，或者對數(shù)據(jù)結(jié)構(gòu)和處理有高級要求的應(yīng)用淋袖，選擇Redis。

二锯梁、memcache使用場景：

1即碗、在動態(tài)系統(tǒng)中減少數(shù)據(jù)庫負載，提升性能陌凳，做緩存剥懒，適合多讀少寫，大數(shù)據(jù)量的情況（如人人網(wǎng)大量查詢用戶信息合敦、好友信息初橘、文章信息等）。它的一個總原則是將經(jīng)常需要從數(shù)據(jù)庫讀取的數(shù)據(jù)緩存在memcached中充岛，這些數(shù)據(jù)也分為幾類：

（1）經(jīng)常被讀取并且實時性要求不強可以等到自動過期的數(shù)據(jù)保檐。例如網(wǎng)站首頁最新文章列表、某某排行等數(shù)據(jù)崔梗。也就是雖然新數(shù)據(jù)產(chǎn)生了夜只，但對用戶體驗不會產(chǎn)生任何影響的場景。這類數(shù)據(jù)就使用典型的緩存策略蒜魄，設(shè)置一過合理的過期時間扔亥，當數(shù)據(jù)過期以后再從數(shù)據(jù)庫中讀取场躯。當然你得制定一個緩存清除策略，便于編輯或者其它人員能馬上看到效果旅挤。

（2）經(jīng)常被讀取并且實時性要求強的數(shù)據(jù)踢关。比如用戶的好友列表，用戶文章列表谦铃，用戶閱讀記錄等耘成。這類數(shù)據(jù)首先被載入到memcached中，當發(fā)生更改（添加驹闰、修改、刪除）時就清除緩存撒会。在緩存的時候嘹朗，我將查詢的SQL語句md5（）得到它的 hash值作為key,結(jié)果數(shù)組作為值寫入memcached，并且將該SQL涉及的table_name以及hash值配對存入memcached中诵肛。 當更改了這個表時屹培，我就將與此表相配對的key的緩存全部刪除。

2怔檩、秒殺功能：一個人下單褪秀，要牽涉數(shù)據(jù)庫讀取，寫入訂單薛训，更改庫存媒吗，及事務(wù)要求， 對于傳統(tǒng)型數(shù)據(jù)庫來說乙埃，壓力是巨大的闸英。

可以利用 memcached 的 incr/decr 功能， 在內(nèi)存存儲 count 庫存量介袜， 秒殺 1000 臺每人搶單主要在內(nèi)存操作甫何，速度非常快遇伞，搶到 count < =1000 的號人辙喂，得一個訂單號，這時再去另一個頁面慢慢支付鸠珠。

三巍耗、不適用memcached的業(yè)務(wù)場景：

? ? ? ? ? 1、緩存對象的大小大于1MB跳芳；

? ? ? ? ? 2芍锦、key的長度大于250字符（所以我們把一些key先md5再存儲）；

? ? ? ? ? 3飞盆、應(yīng)用運行在不安全的環(huán)境中Memcached為提供任何安全策略娄琉，僅僅通過telnet就可以訪問到memcached次乓。如果應(yīng)用運行在共享的系統(tǒng)上，需要著重考慮安全問題孽水；

? ? ? ? ? 4票腰、業(yè)務(wù)本身需要的是持久化數(shù)據(jù)。

四女气、Redis場景：適用于對讀寫效率要求都很高杏慰，數(shù)據(jù)處理業(yè)務(wù)復(fù)雜和對安全性要求較高的系統(tǒng)（如新浪微博的計數(shù)和微博發(fā)布部分系統(tǒng)，對數(shù)據(jù)安全性炼鞠、讀寫要求都很高）缘滥、Pub/Sub構(gòu)建實時消息系統(tǒng)、統(tǒng)計谒主。

區(qū)別：

? ? ? ? ? 1朝扼、存儲方式：Memcache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會掛掉霎肯，數(shù)據(jù)不能超 過內(nèi)存大小擎颖。Redis支持數(shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保存在磁盤中观游，重啟時可以再次加載進行使用搂捧。（RDB快照和AOF日志兩 種持久化方式）。

? ? ? ? ? 2懂缕、Redis支持數(shù)據(jù)的備份允跑，及master-slave模式的數(shù)據(jù)備份。

? ? ? ? ? 3提佣、數(shù)據(jù)支持類型：Redis在數(shù)據(jù)支持上要比Memcache多得多吮蛹。

? ? ? ? ? 4、使用底層模型不同：新版本的Redis直接自己構(gòu)建了VM機制拌屏，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話潮针，會浪費一定的時間去移動和請求。

? ? ? ? ? 5倚喂、 redis有一個致命缺陷 當內(nèi)存滿了時 dump數(shù)據(jù)cpu占用100%每篷。

總結(jié)：

? ? ? ? ? 1、Redis使用最佳方式是全部數(shù)據(jù)in-memory端圈。

? ? ? ? ? 2焦读、Redis更多場景是作為Memcache的替代者來使用。

? ? ? ? ? 3舱权、當需要除key/value之外的更多數(shù)據(jù)類型支持時矗晃，使用Redis更合適。

? ? ? ? ? 4宴倍、當存儲的數(shù)據(jù)不能被剔除時张症，使用Redis更合適仓技。

? ? ? ? ? 5、如果要說內(nèi)存使用效率俗他，使用簡單的key-value存儲的話脖捻，Memcached的內(nèi)存利用率更高，而如果Redis采用hash結(jié)構(gòu)來做key-value存儲兆衅，由于其組合式的壓縮地沮，其內(nèi)存利用率會高于Memcached。當然羡亩，這和你的應(yīng)用場景和數(shù)據(jù)特性有關(guān)摩疑。

Memcache應(yīng)用場景介紹，說明[zz]:

http://www.cnblogs.com/literoad/archive/2012/12/23/2830178.html