memecached和redis的主要区别：
1、存储方式：
memecached 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；
redis 有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（两种持久化方式：快照和AOF日志。在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做dump）。
2、数据支持类型：
redis在数据支持上要比memecache多很多，redis支持5种数据类型有：字符串、散列、列表、集合、有序集合。
3、使用底层模型不同：
新版本的redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4、运行环境不同：
redis目前官方只支持LINUX上去运行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统环境上的优化，虽然后来微软有一个小组为其写了补丁，但是没有放到主干上。
小结：，有持久化需求或者对数据结构和处理有高级要求的应用，选择redis，其他简单的key/value存储，选择memcached。
memcached和Redis选择 ，详细如下：
这个问题总会时不时出现、并给每一位开发人员带来困扰。在考虑对应用程序的性能表现进行提升时，缓存机制往往是解决问题的重要起点，而Memcached与Redis则经常被作为初步方案来加以比较。
这两套声名显赫的缓存引擎拥有着诸多相似之处，但它们同样也具备大量显著差异。
作为二者当中更年轻也更加灵活的方案，Redis被大部分技术人员视为首选目标——但请别掉以轻心，不容忽视的重要例外情况也是客观存在的。
两者相似之处:
Memcached与Redis都属于内存内、键值数据存储方案。它们都从属于数据管理解决方案中的NoSQL家族，而且都基于同样的键值数据模型。双方都选择将全部数据保存在内存当中，这自然也就让它们成为非常理想的缓冲层实现方案。从性能表现的角度来看，两类数据存储机制也具备诸多共通性，包括拥有几乎相同的特征(与指标)表现、而且高度关注工作负载的数据吞吐量与延迟状况。
除了同为内存内键值数据存储方案，Memcached与Redis还都是相当成熟而且极具人气的开源项目。Memcached最初是由Brad Fitzpatrick于2003年开发而成，当时其直接服务对象为LiveJournal交友网站。在此之后，Memcached被重新用C语言进行了编写(其最初实现方式为Perl语言)且投身于公共领域，并在这里逐步发展为现代Web应用程序的构建基石。Memcached项目的当前开发工作主要关注其运行稳定性及优化效果方面，而不再积极为其打造更多新型功能。
Redis则由Salvatore Sanfilippo于2009年创建，而且时至今日Sanfilippo仍然担任着该项目的首席开发者以及惟一维护者的角色。Redis有时候会被人们称为“强化版的Memcached”。考虑到从Memcached身上吸取并借鉴到大量宝贵的经验教训，这样的评价其实并不令人意外。Redis在功能多样性方面要胜过Memcached，这虽然让者更为强大也更具灵活性、但其复杂程度也较后者为甚。
作为两套被众多企业采纳并部署在无数关键性生产任务环境当中的解决方案，Memcached与Redis在任何一种可行性编程语言领域都拥有能够提供支持的客户端库，而且二者也被包含在开发人员们使用的多种库及软件包之内。事实上，现在我们甚至已经很难找到一套不包含Memcached或者Redis内置支持机制的Web堆栈。
Memcached与Redis为什么如此受人拥戴?除了二者卓越的实际效果之外，双方各自极为简便的上手难度也是又一大加分项。无论是Memcached还是Redis，其使用便捷性在开发人员当中都可谓广为人知。只需要几分钟我们就能完成安装工作，并让它们开始与应用程序顺畅协作。换句话来说，只需投入一小部分时间与精力，大家就能获得立竿见影且效果极佳的性能表现提升——具体而言，性能将直接步入新的量级。面对如此简单而又能够带来巨大收益的解决方案，又有谁能抗拒得了它们的诱惑呢?
何时应该使用Memcached
相对Memcached而言，Redis的面世时间更晚且具备更多功能，因此开发人员通常将其视为默认性首选方案。不过有两类特殊场景仍然是Memcached的一家天下。首先就是对小型静态数据进行缓存处理，最具代表性的例子就是HTML代码片段。Memcached的内部内存管理机制虽然不像Redis的那样复杂，但却更具实际效率——这是因为Memcached在处理元数据时所消耗的内存资源相对更少。作为Memcached所支持的惟一一种数据类型，字符串非常适合用于保存那些只需要进行读取操作的数据，因为字符串本身无需进行进一步处理。
除此之外，Memcached在横向扩展方面也比Redis更具优势。由于其在设计上的思路倾向以及相对更为简单的功能设置，Memcached在实现扩展时的难度比Redis低得多。不过根据我们了解到的情况，目前已经有多种经过测试且切实有效的方案能够将Redis扩展至多台服务器之上，而其即将发布的3.0版本(感兴趣的朋友可以点击此处查看其候选版本说明)将包含专门针对横向扩展场景的内置集群化机制。
何时应该使用Redis
除非大家需要考虑某种限定性条件(例如处理传统应用程序)对于Memcached的特殊依赖性，或者自己的实际用例属于前面提到的两类场景中的一种，否则请直接选择Redis并加以运用。
凭借着Redis所带来的卓越缓存方案，我们将拥有强大的处理能力——例如对缓存内容及持久性进行细节调整的能力——以及出色的整体执行效率。
Redis几乎在缓存管理工作中的每一个侧面都表现出显而易见的优越性。这套缓存方案采用所谓数据回收机制，能够将陈旧数据从内存中删除以提供新数据所必需的缓存空间。Memcached的数据回收机制使用的是LRU(即最低近期使用量)算法，而且往往会比较武断地直接删除掉与新数据体系相近的原有内容。相比之下，Redis允许用户更为精准地进行细化控制，利用六种不同回收策略确切提高缓存资源的实际利用率。Redis还采用更为复杂的内存管理与回收对象备选方案。
Redis还能为我们带来最大程度的灵活性空间，从而保证管理员在打理缓存对象时拥有充裕的施展平台。在这方面，Memcached将键名限制在250字节，值也被限制在不超过1MB，且只适用于普通字符串。相比之下，Redis则将键名与值的最大上限各自设定为512MB，且支持二进制格式。Redis支持六种数据类型，因此能够更加智能地对数据进行缓存处理及操作，这相当于为应用程序开发人员敞开了一道通往无尽可能性的大门。
相对于将对象保存为序列化字符串，Redis允许开发人员以散列方式将对象域及值加以保存，并利用单一键对其进行管理。Redis散列机制的存在保证开发人员无需经历获取完整字符串、反序列化、更新值、对象重新序列化并在每次值更新后利用其替代缓存内完整字符串这一系列复杂的流程——这也意味着资源消耗量得以降低、性能表现迎来显著提升。Redis所支持的其它数据类型，例如Lists以及Sets——也可被用于实现更加复杂的缓存管理模式。
Redis的另一大重要优势在于，它所保存的数据具备透明化特性，也就是说服务器能够直接对这些数据进行操作。Redis当中提供160多种可用命令，其中大部分用于实现数据处理操作并通过服务器端脚本将逻辑嵌入至数据存储体系当中。这些内置命令及用户脚本带来了极大的灵活性优势，足以帮助大家直接在Redis内部完成数据处理任务——而不必将数据在网络中的其它专门处理系统之间来回移动。
Redis还提供可选而且能够具体调整的数据持久性方案，其设计目的在于在发生规划内停机或者计划外故障之后对缓存内容进行重新引导。虽然我们更倾向于强调缓存内数据的易失性与暂时性，但将数据在磁盘中加以持久保存在某些缓存场景当中仍然极具现实意义。这种机制能够在设备重启之后快速将保存在磁盘上的数据重新载入至缓存当中，从而大大缩短缓存预热周期并根据主数据存储内容对当前缓存内容进行重新评估。
最后但也同样重要的一点是，Redis能够提供复制功能。复制功能旨在帮助缓存体系实现高可用性配置方案，从而在遭遇故障的情况下继续为应用程序提供不间断的缓存服务。很明显，一套成熟的缓存方案应该能够在应用程序发生故障时略微甚至完全不给用户体验或者应用程序性能表现带来任何影响，而这种对缓存内容及服务可用性的有力保障在大多数情况下也成为缓存解决方案的一大主要优势。
从功能多样性以及设计先进性的角度出发，Redis显然更适合被大家作为通用性的首选方案——除了少部分特殊场景之外。
其它：
在选择缓存时到底什么时候选择redis，什么时候选择memcache，下面是redis作者的说法：
You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.
You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don’t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).
以上重点：
Redis只使用单核，而Memcached可以使用多核；
Redis支持数据持久化和主从复制，memcached则不行；
1、存储方式：
memecached 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；
redis 有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（两种持久化方式：快照和AOF日志。在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做dump）。
2、数据支持类型：
redis在数据支持上要比memecache多很多，redis支持5种数据类型有：字符串、散列、列表、集合、有序集合。
3、使用底层模型不同：
新版本的redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4、运行环境不同：
redis目前官方只支持LINUX上去运行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统环境上的优化，虽然后来微软有一个小组为其写了补丁，但是没有放到主干上。
小结：，有持久化需求或者对数据结构和处理有高级要求的应用，选择redis，其他简单的key/value存储，选择memcached。
memcached和Redis选择 ，详细如下：
这个问题总会时不时出现、并给每一位开发人员带来困扰。在考虑对应用程序的性能表现进行提升时，缓存机制往往是解决问题的重要起点，而Memcached与Redis则经常被作为初步方案来加以比较。
这两套声名显赫的缓存引擎拥有着诸多相似之处，但它们同样也具备大量显著差异。
作为二者当中更年轻也更加灵活的方案，Redis被大部分技术人员视为首选目标——但请别掉以轻心，不容忽视的重要例外情况也是客观存在的。
两者相似之处:
Memcached与Redis都属于内存内、键值数据存储方案。它们都从属于数据管理解决方案中的NoSQL家族，而且都基于同样的键值数据模型。双方都选择将全部数据保存在内存当中，这自然也就让它们成为非常理想的缓冲层实现方案。从性能表现的角度来看，两类数据存储机制也具备诸多共通性，包括拥有几乎相同的特征(与指标)表现、而且高度关注工作负载的数据吞吐量与延迟状况。
除了同为内存内键值数据存储方案，Memcached与Redis还都是相当成熟而且极具人气的开源项目。Memcached最初是由Brad Fitzpatrick于2003年开发而成，当时其直接服务对象为LiveJournal交友网站。在此之后，Memcached被重新用C语言进行了编写(其最初实现方式为Perl语言)且投身于公共领域，并在这里逐步发展为现代Web应用程序的构建基石。Memcached项目的当前开发工作主要关注其运行稳定性及优化效果方面，而不再积极为其打造更多新型功能。
Redis则由Salvatore Sanfilippo于2009年创建，而且时至今日Sanfilippo仍然担任着该项目的首席开发者以及惟一维护者的角色。Redis有时候会被人们称为“强化版的Memcached”。考虑到从Memcached身上吸取并借鉴到大量宝贵的经验教训，这样的评价其实并不令人意外。Redis在功能多样性方面要胜过Memcached，这虽然让者更为强大也更具灵活性、但其复杂程度也较后者为甚。
作为两套被众多企业采纳并部署在无数关键性生产任务环境当中的解决方案，Memcached与Redis在任何一种可行性编程语言领域都拥有能够提供支持的客户端库，而且二者也被包含在开发人员们使用的多种库及软件包之内。事实上，现在我们甚至已经很难找到一套不包含Memcached或者Redis内置支持机制的Web堆栈。
Memcached与Redis为什么如此受人拥戴?除了二者卓越的实际效果之外，双方各自极为简便的上手难度也是又一大加分项。无论是Memcached还是Redis，其使用便捷性在开发人员当中都可谓广为人知。只需要几分钟我们就能完成安装工作，并让它们开始与应用程序顺畅协作。换句话来说，只需投入一小部分时间与精力，大家就能获得立竿见影且效果极佳的性能表现提升——具体而言，性能将直接步入新的量级。面对如此简单而又能够带来巨大收益的解决方案，又有谁能抗拒得了它们的诱惑呢?
何时应该使用Memcached
相对Memcached而言，Redis的面世时间更晚且具备更多功能，因此开发人员通常将其视为默认性首选方案。不过有两类特殊场景仍然是Memcached的一家天下。首先就是对小型静态数据进行缓存处理，最具代表性的例子就是HTML代码片段。Memcached的内部内存管理机制虽然不像Redis的那样复杂，但却更具实际效率——这是因为Memcached在处理元数据时所消耗的内存资源相对更少。作为Memcached所支持的惟一一种数据类型，字符串非常适合用于保存那些只需要进行读取操作的数据，因为字符串本身无需进行进一步处理。
除此之外，Memcached在横向扩展方面也比Redis更具优势。由于其在设计上的思路倾向以及相对更为简单的功能设置，Memcached在实现扩展时的难度比Redis低得多。不过根据我们了解到的情况，目前已经有多种经过测试且切实有效的方案能够将Redis扩展至多台服务器之上，而其即将发布的3.0版本(感兴趣的朋友可以点击此处查看其候选版本说明)将包含专门针对横向扩展场景的内置集群化机制。
何时应该使用Redis
除非大家需要考虑某种限定性条件(例如处理传统应用程序)对于Memcached的特殊依赖性，或者自己的实际用例属于前面提到的两类场景中的一种，否则请直接选择Redis并加以运用。
凭借着Redis所带来的卓越缓存方案，我们将拥有强大的处理能力——例如对缓存内容及持久性进行细节调整的能力——以及出色的整体执行效率。
Redis几乎在缓存管理工作中的每一个侧面都表现出显而易见的优越性。这套缓存方案采用所谓数据回收机制，能够将陈旧数据从内存中删除以提供新数据所必需的缓存空间。Memcached的数据回收机制使用的是LRU(即最低近期使用量)算法，而且往往会比较武断地直接删除掉与新数据体系相近的原有内容。相比之下，Redis允许用户更为精准地进行细化控制，利用六种不同回收策略确切提高缓存资源的实际利用率。Redis还采用更为复杂的内存管理与回收对象备选方案。
Redis还能为我们带来最大程度的灵活性空间，从而保证管理员在打理缓存对象时拥有充裕的施展平台。在这方面，Memcached将键名限制在250字节，值也被限制在不超过1MB，且只适用于普通字符串。相比之下，Redis则将键名与值的最大上限各自设定为512MB，且支持二进制格式。Redis支持六种数据类型，因此能够更加智能地对数据进行缓存处理及操作，这相当于为应用程序开发人员敞开了一道通往无尽可能性的大门。
相对于将对象保存为序列化字符串，Redis允许开发人员以散列方式将对象域及值加以保存，并利用单一键对其进行管理。Redis散列机制的存在保证开发人员无需经历获取完整字符串、反序列化、更新值、对象重新序列化并在每次值更新后利用其替代缓存内完整字符串这一系列复杂的流程——这也意味着资源消耗量得以降低、性能表现迎来显著提升。Redis所支持的其它数据类型，例如Lists以及Sets——也可被用于实现更加复杂的缓存管理模式。
Redis的另一大重要优势在于，它所保存的数据具备透明化特性，也就是说服务器能够直接对这些数据进行操作。Redis当中提供160多种可用命令，其中大部分用于实现数据处理操作并通过服务器端脚本将逻辑嵌入至数据存储体系当中。这些内置命令及用户脚本带来了极大的灵活性优势，足以帮助大家直接在Redis内部完成数据处理任务——而不必将数据在网络中的其它专门处理系统之间来回移动。
Redis还提供可选而且能够具体调整的数据持久性方案，其设计目的在于在发生规划内停机或者计划外故障之后对缓存内容进行重新引导。虽然我们更倾向于强调缓存内数据的易失性与暂时性，但将数据在磁盘中加以持久保存在某些缓存场景当中仍然极具现实意义。这种机制能够在设备重启之后快速将保存在磁盘上的数据重新载入至缓存当中，从而大大缩短缓存预热周期并根据主数据存储内容对当前缓存内容进行重新评估。
最后但也同样重要的一点是，Redis能够提供复制功能。复制功能旨在帮助缓存体系实现高可用性配置方案，从而在遭遇故障的情况下继续为应用程序提供不间断的缓存服务。很明显，一套成熟的缓存方案应该能够在应用程序发生故障时略微甚至完全不给用户体验或者应用程序性能表现带来任何影响，而这种对缓存内容及服务可用性的有力保障在大多数情况下也成为缓存解决方案的一大主要优势。
从功能多样性以及设计先进性的角度出发，Redis显然更适合被大家作为通用性的首选方案——除了少部分特殊场景之外。
其它：
在选择缓存时到底什么时候选择redis，什么时候选择memcache，下面是redis作者的说法：
You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.
You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don’t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).
以上重点：
Redis只使用单核，而Memcached可以使用多核；
Redis支持数据持久化和主从复制，memcached则不行；
对于两者的选择需要要看具体的应用场景，如果需要缓存的数据只是key-value这样简单的结构时，则还是采用memcache，它也足够的稳定可靠。如果涉及到存储，排序等一系列复杂的操作时，毫无疑问选择redis。
转自：http://www.coin163.com/good/blog/memcached-redis.html