我认为今天Memcached胜过Redis的用例的主要原因是，您应该能够使用普通的HTML片段缓存(或类似的应用程序)获得更高的内存效率。如果您需要将对象的不同字段存储在不同的Memcached键中，那么Redis散列将会更高效地存储内存，但是当您有大量的键->Simple_String键对时，Memcached应该能够为您提供更多的每兆字节的项。

Memcached的其他优点：

• 这是一段非常简单的代码，所以如果你只需要它提供的功能，我想它是一个合理的替代方案，但我从未在生产中使用过它。
• 它是多线程的，所以如果您需要在单盒设置中进行扩展，这是一件好事，您只需要与一个示例进行对话。

我相信，随着人们转向智能缓存，或者当他们试图通过Redis数据结构保存缓存数据的结构时，Redis作为缓存越来越有意义。

Redis LRU与Memcach LRU对比。

Memcached和Redis都不执行真正的LRU逐出，而只是近似地执行。

内存缓存逐出是按大小的类，取决于它的片分配器的实现细节。例如，如果您要添加适合给定大小类的项，则Memcached将尝试删除该类中过期/最近不使用的项，而是尝试全局尝试了解对象是什么，而不考虑其大小，这是最佳候选对象。

相反，当达到maxmemory限制时，Redis会尝试挑选一个好的对象作为驱逐的候选对象，查看所有对象，而不是大小类别，但只能提供大致好的对象，而不是空闲时间较长的“最佳对象”。

Redis做到这一点的方法是采样几个对象，选择空闲(未访问)时间最长的对象。自Redis 3.0(目前处于测试版)以来，该算法得到了改进，并且还在驱逐过程中采用了很好的候选者池，因此近似值得到了改进。在Redis documentation you can find a description and graphs with details about how it works中。

为什么对于简单的字符串->字符串Map，Memcached比Redis有更好的内存占用。

Redis是一个更复杂的软件，所以Redis中的值以一种更类似于高级编程语言中的对象的方式存储：它们具有关联的类型、编码、用于内存管理的引用计数。这使得Redis的内部结构良好且易于管理，但与只处理字符串的Memcached相比，它有一定的开销。

Redis何时开始提高内存效率

Redis能够以一种特殊的内存节约方式存储小聚合数据类型。例如，表示对象的小Redis哈希在内部存储，而不是使用哈希表，而是作为二进制唯一BLOB。因此，将每个对象的多个字段设置为一个散列比将N个单独的键存储到Memcached中更有效。

实际上，您可以将对象作为单个JSON(或二进制编码的)BLOB存储到Memcached中，但与Redis相反，这不允许您获取或更新独立的字段。

Redis在智能缓存方面的优势。

由于Redis的数据结构，在缓存失效时销毁对象、稍后从数据库重新创建缓存的常用模式是使用Redis的原始方式。

例如，假设您需要缓存发布到Hacker News中的最新N条新闻，以便填充站点的“最新”部分。你在Redis上所做的就是列出一个列表(最多M个项目)，并插入最新的新闻。如果您使用另一个存储数据的存储，并使用Redis作为缓存，那么当一个新条目发布时，您要做的就是填充这两个视图(Redis和DB)。不存在缓存失效。

然而，应用程序可以始终具有逻辑，这样，如果发现Redis列表为空，例如在启动后，可以从数据库重新创建初始视图。

通过使用智能缓存，可以使用Redis以比Memcached更高效的方式执行缓存，但并不是所有的问题都适合这种模式。例如，HTML片段缓存可能不会从这项技术中受益。

习惯很难改掉：)

不过，说真的，据我所知，仍在使用Memcach的主要原因有两个：

1.遗留--熟悉Memcached的开发人员，以及支持它的应用程序。这也意味着它是一项成熟且经过充分测试的技术。
1.伸缩--标准的Memcached很容易水平伸缩，而Redis(直到并不包括即将发布的v3)需要做更多的工作(即分片)。

但是：

1.Re.遗留--考虑到Redis的健壮性(数据结构、命令、持久性……)，它正在被积极地开发，并且客户使用每一种可以想到的语言--新的应用程序通常都是用它开发的。
1.重新伸缩-除了即将发布的v3，还有一些解决方案可以让伸缩变得更容易。例如，Redis Cloud提供无缝扩展，不会丢失数据或中断服务。缩放/分片Redis的另一种流行方法是twemproxy。