一、Memcache
1．memecache 把資料全部存在記憶體之中，斷電後會掛掉，資料不能超過記憶體大小
redis有部份存在硬碟上，這樣能保證資料的永續性。
2．Memcache使用了Slab Allocator的記憶體分配機制:按照預先規定的大小，將分配的記憶體分割成特定長度的塊，以完全解決記憶體碎片問題。
3．memcache 存在記憶體中，分配的記憶體滿後，會按一定的規則刪除一些k/v資料，重啟後自然全部丟失。
4．過期策略--memcache在set時就指定，例如set key1 0 0 8,即永不過期。Redis可以通過例如expire 設定。
5．首先要說明的是Memcached支援最大的儲存物件為1M。它的記憶體分配比較特殊，但是這樣的分配方式其實也是基於效能考慮的，簡單的分配機制可以更容易回收再分配，節省對CPU的使用。大於1M需要拆分。
6．memcached能接受的key的最大長度是，255字元。
7．同一份資料同時傳送了一個set命令和一個get命令，它們不會影響對方，但是get以後，處理期間可能先被其他Set了，後面的Set會覆蓋前面的，但是memcached 1.2.5以及更高版本，提供了gets和cas命令，它們可以解決上面的問題。如果您使用gets命令查詢某個key的item，memcached會 給您返回該item當前值的唯一標識。如果您覆寫了這個item並想把它寫回到memcached中，您可以通過cas命令把那個唯一標識一起傳送給 memcached。如果該item存放在memcached中的唯一標識與您提供的一致，您的寫操作將會成功。如果另一個程序在這期間也修改了這個 item，那麼該item存放在memcached中的唯一標識將會改變，您的寫操作就會失敗。
8．無身份驗證，認為身份驗證是更高層的問題。
9．刪除Delete操作只是將該chunk置為刪除狀態，這樣在下次使用將優先利用這樣的chunk。
10．Flush操作相當於將所有的item失效的一個動作。並不會改變memcache記憶體分配情況。
11．memcache已經分配的記憶體不會再主動清理。
12．memcache分配給某個slab的記憶體頁不能再分配給其他slab。
13．flush_all不能重置memcache分配記憶體頁的格局，只是給所有的item置為過期。
14．memcache最大儲存的item(key+value)大小限制為1M，這由page大小1M限制。
15．由於memcache的分散式是客戶端程式通過hash演算法得到的key取模來實現，不同的語言可能會採用不同的hash演算法，同樣的客戶端程式也有可能使用相異的方法，因此在多語言、多模組共用同一組memcached服務時，一定要注意在客戶端選擇相同的hash演算法。
16．啟動memcached時可以通過-M引數禁止LRU替換，在記憶體用盡時add和set會返回失敗。
17．memcached啟動時指定的是資料儲存量，沒有包括本身佔用的記憶體、以及為了儲存資料而設定的管理空間。因此它佔用的記憶體量會多於啟動時指定的記憶體分配量，這點需要注意。
二、Redis
1．  Redis不僅僅支援簡單的k/v型別的資料，同時還提供list，set，hash等資料結構的儲存。
2．  Redis支援資料的備份，即master-slave模式的資料備份。
3．  Redis支援資料的持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用。
4．  Redis，具備一定的資料庫特徵。
5．  Redis資料可以儲存到硬碟，基本沒有過期策略。
6．  redis有一個致命缺陷 當記憶體滿了時 dump資料cpu佔用100%。
三、Memcache和Redis區別
Redis中，並不是所有的資料都一直儲存在記憶體中的，這是和Memcached相比一個最大的區別。
Redis在很多方面具備資料庫的特徵，或者說就是一個數據庫系統，而Memcached只是簡單的K/V快取。
他們的擴充套件都需要做叢集；實現方式：master-slave、Hash。
在100k以上的資料中，Memcached效能要高於Redis。
如果要說記憶體使用效率，使用簡單的key-value儲存的話，Memcached的記憶體利用率更高，而如果Redis採用hash結構來做key-value儲存，由於其組合式的壓縮，其記憶體利用率會高於Memcached。當然，這和你的應用場景和資料特性有關。
如果你對資料持久化和資料同步有所要求，那麼推薦你選擇Redis，因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統後快取資料不會丟失，選擇Redis也是明智的。

Redis和Memcache在寫入效能上面差別不大，讀取效能上面尤其是批量讀取效能上面Memcache更強。

選擇參考：

   沒有必要過多的關注效能。由於Redis只使用單核，而Memcached可以使用多核，所以在比較上，平均每一個核上Redis在儲存小資料時比Memcached效能更高。而在100k以上的資料中，Memcached效能要高於Redis，雖然Redis最近也在儲存大資料的效能上進行優化，但是比起Memcached，還是稍有遜色。說了這麼多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。
   你需要關注記憶體使用率。對於key-value這樣簡單的資料儲存，memcache的記憶體使用率更高。如果採用hash結構，redis的記憶體使用率會更高。當然，這些都依賴於具體的應用場景。
   你需要關注關注資料持久化和主從複製時，只有redis擁有這兩個特性。如果你的目標是構建一個快取在升級或者重啟後之前的資料不會丟失的話，那也只能選擇redis。
   你應該關心你需要的操作。redis支援很多複雜的操作，甚至只考慮記憶體的使用情況，在一個單一操作裡你常常可以做很多，而不需要將資料讀取到客戶端中（這樣會需要很多的IO操作）。這些複雜的操作基本上和純GET和POST操作一樣快，所以你不只是需要GET/SET而是更多的操作時，redis會起很大的作用。
   對於兩者的選擇還是要看具體的應用場景，如果需要快取的資料只是key-value這樣簡單的結構時，我在專案裡還是採用memcache，它也足夠的穩定可靠。如果涉及到儲存，排序等一系列複雜的操作時，毫無疑問選擇redis。  
   關於redis和memcache的不同，下面羅列了一些相關說法，供記錄：
   redis和memecache的不同在於[2]：
   1、儲存方式：
   memecache 把資料全部存在記憶體之中，斷電後會掛掉，資料不能超過記憶體大小
   redis有部份存在硬碟上，這樣能保證資料的永續性，支援資料的持久化（筆者注：有快照和AOF日誌兩種持久化方式，在實際應用的時候，要特別注意配置檔案快照引數，要不就很有可能伺服器頻繁滿載做dump）。
   2、資料支援型別：
   redis在資料支援上要比memecache多的多。
   3、使用底層模型不同：
   新版本的redis直接自己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。
   4、執行環境不同：
   redis目前官方只支援LINUX 上去行，從而省去了對於其它系統的支援，這樣的話可以更好的把精力用於本系統 環境上的優化，雖然後來微軟有一個小組為其寫了補丁。但是沒有放到主幹上
個人總結一下，有持久化需求或者對資料結構和處理有高階要求的應用，選擇redis，其他簡單的key/value儲存，選擇memcache。

轉自：http://www.cnblogs.com/gowhy/archive/2012/12/20/2826819.html

    http://tech.ddvip.com/2013-11/1384431855205966.html