1、線程問題
由于Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高于Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起 Memcached，還是稍有遜色。
因為 Redis 的操作都非常快速——它的數據全部在內存里，完全不需要訪問磁盤。至于并發，Redis 使用多路 I/O 復用技術，本身的并發效率不成問題。
當然，單個 Redis 進程沒辦法使用多核（任一時刻只能跑在一個 CPU 核心上），但是它本來就不是非常計算密集型的服務。如果單核性能不夠用，可以多開幾個進程。
Redis 單線程-多路復用io模型
、
2、內存使用效率對比：
使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis采用hash結構來做key-value存儲，由于其組合式的壓縮，其內存利用率會高于Memcached。
3、數據類型：
Redis相比Memcached來說，擁有更多的數據結構和并支持更豐富的數據操作，通常在Memcached 里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網絡IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的 GET/SET一樣高效。所以，如果需要緩存能夠支持更復雜的結構和操作，那么Redis會是不錯的選擇。
4、安全機制
memcached采用cas機制，而redis有事務機制。
5、事件模型
memcached采用了libevent事件模型，多線程模型可以發揮多核作用，Redis實現了自己的一套和libevent類似的事件驅動機制，兩者都采用了epoll通信模型和非阻塞機制。
epoll是在2.6內核中提出的，是之前的select和poll的增強版本。相對于select和poll來說，epoll更加靈活，沒有描述符限制。epoll使用一個文件描述符管理多個描述符，將用戶關系的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的copy只需一次。
最后講講 為什么epoll會比select高效，主要從三方面來進行論述。
（1）elect對描述符狀態的改變是通過輪詢來進行查找的；而epoll是當描述符狀態發生改變時主動進行通知內核，這就是所謂的Reactor事件處理機制。可以用“好萊塢原則”進行描述：不要打電話給我們，我們會打電話通知你。相比之下，select的機制就好比面試結束后不停給面試官打電話詢問面試結果。效率孰高孰低，可見一 斑。
（2）select的文件描述符是使用鏈表進行組織的；而epoll是使用紅黑樹這一高效數據結構組織的。
（3）select從內核到用戶空間傳遞文件描述符上發送的信息是使用內存復制的方式進行的；而epoll是采用共享內存的方式。
6、內存管理方面
Memcached使用預分配的內存池的方式，使用slab和大小不同的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內存池的方式可以省去申請/釋放內存的開銷，并且能減小內存碎片產生，但這種方式也會帶來一定程度上的空間浪費，并且在內存仍然有很大空間時，新的數據也可能會被剔除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用現場申請內存的方式來存儲數據，并且很少使用free-list等方式來優化內存分配，會在一定程度上存在內存碎片，Redis跟據存儲命令參數，會把帶過期時間的數據單獨存放在一起，并把它們稱為臨時數據，非臨時數據是永遠不會被剔除的，即便物理內存不夠，導致swap也不會剔除任何非臨時數據(但會嘗試剔除部分臨時數據)，這點上Redis更適合作為存儲而不是cache。
7、redis并發
Redis 是一個高性能的key-value數據庫。 redis的出現，很大程度補償了memcached這類keyvalue存儲的不足，在部 分場合可以對關系數據庫起到很好的補充作用。它提供了Python，Ruby，Erlang，PHP客戶端，使用很方便。
性能測試結果：
SET操作每秒鐘 110000 次，GET操作每秒鐘 81000 次，服務器配置如下：
Linux 2.6, Xeon X3320 2.5Ghz.
stackoverflow 網站使用 Redis 做為緩存服務器。