问如果Redis已经是堆栈的一部分，那么为什么Memcached仍然与redis一起使用呢？

EN

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

其他关于memcached的优点是：

• 这是一段非常简单的代码，所以如果您只需要它提供的功能，我想这是一个合理的选择，但我从未在生产中使用过它。
• 它是多线程的，所以如果您需要在单盒设置中进行缩放，这是一件好事，您只需要与一个实例进行交谈。

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

Redis LRU与memcached LRU的比较

memcached和Redis都不执行真正的LRU驱逐，但这只是一个近似值。

Memcache逐出是按大小的类，并取决于其块分配器的实现细节。例如，如果要添加适合给定大小类的项，memcached将尝试删除该类中过期/非最近使用的项，而不是尝试全局尝试了解对象是什么，而不管对象大小如何，这是最好的候选项。

相反，Redis试图在达到maxmemory限制时选择一个好对象作为驱逐的候选对象，查看所有对象，而不管大小类如何，但只能提供一个大约很好的对象，而不是具有更多空闲时间的最佳对象。

Redis这样做的方法是对几个对象进行采样，选择一个空闲时间最长的对象(而不是访问对象)。自从Redis3.0(目前处于beta版)以来，该算法得到了改进，并且在逐出过程中使用了一个很好的候选池，因此改进了近似。在Redis文档您可以找到描述和图表，详细说明它是如何工作的。里。

为什么memcached对于简单的字符串->字符串映射比Redis具有更好的内存占用。

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

当Redis开始提高内存效率时

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

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

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

由于Redis数据结构，与memcached一起使用的通常模式是在缓存失效时破坏对象，稍后从DB重新创建对象，这是使用Redis的一种原始方式。

例如，假设您需要将最新的N条新闻缓存到Hacker news中，以填充站点的“最新”部分。你对Redis所做的就是用最新的新闻来获取一个列表(以M条目为上限)。如果您为您的数据使用另一个存储区，并且使用Redis作为缓存，那么您所做的就是在发布新项时同时填充视图(Redis和DB)。没有缓存失效。

但是，应用程序可以始终具有逻辑，以便如果发现Redis列表为空(例如在启动后)，则可以从DB重新创建初始视图。

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

习惯很难改掉:)

然而，说真的，有两个主要原因--据我理解--为什么Memcached仍然被使用：

1. 旧式--那里的开发人员对Memcached以及支持Memcached的应用程序都很熟悉。这也意味着它是一种成熟且经过良好测试的技术.
2. 缩放-标准Memcached是很容易横向可伸缩的，而Redis (直到和排除即将发布的v3)需要为此做更多的工作(即分片)。

然而：

1. Re.遗留--鉴于Redis的健壮性(数据结构、命令、持久性.)，它正在积极开发，而且客户端使用所有可以想到的语言--新的应用程序通常是与它一起开发的。
2. Re scaling --除了即将发布的v3之外，还有一些解决方案可以使扩展变得更加容易。例如，红云提供无缝扩展，不造成数据丢失或服务中断。另一种流行的缩放/切分红宝石的方法是双代理。