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 做为缓存服务器。