Memcached与Redis的对比
我们正在使用一个Ruby web-app，使用Redis服务器进行缓存。是否有必要测试Memcached来代替？
什么会给我们带来更好的性能？Redis和Memcached之间有什么优点或缺点吗？
需要考虑的要点。
- 读取/写入速度。
- 内存使用量。
- 磁盘I/O的转储。
- 可扩展性。
摘要(TL;DR)
已于2017年6月3日更新
Redis比memcached更强大、更流行、更受支持。Memcached只能做Redis能做的一小部分事情。即使在他们功能重叠的地方，Redis也更胜一筹。
对于任何新的东西，都要使用Redis。
Memcached与Redis。直接比较
这两种工具都是强大的、快速的、内存中的数据存储，作为一种缓存很有用。两者都可以通过缓存数据库结果、HTML片段或其他任何可能要花钱生成的东西来帮助加快你的应用程序。
需要考虑的要点
当用于同一件事时，下面是使用原问题的"考虑要点"对它们进行比较的情况。
- 读/写速度：两者都非常快。基准测试因工作负载、版本和许多其他因素而异，但通常显示redis的速度和memcached一样快或几乎一样快。我推荐redis，但不是因为memcached很慢。它不是。
- Memory usage: Redis is better.
- memcached。你指定了缓存的大小，当你插入项目时，守护程序会迅速增长到比这个大小更多一点。除了重启memcached之外，没有任何方法可以重新获得这些空间。你所有的键可能已经过期，你可以刷新数据库，它仍然会使用你配置的全部内存。
- redis：设置最大容量由你决定。Redis永远不会使用超过它必须使用的内存，并且会把不再使用的内存还给你。
- 我把100,000个~2KB的字符串（~200MB）的随机句子存储到这两个地方。Memcached的RAM使用量增加到~225MB。Redis的RAM使用量增长到了~228MB。在刷新两者之后，Redis下降到~29MB，Memcached保持在~225MB。它们在存储数据方面的效率是相似的，但只有一个能够回收数据。
- 磁盘I/O转储。Redis显然是个赢家，因为它在默认情况下会这样做，而且有非常可配置的持久性。Memcached在没有第三方工具的情况下没有向磁盘转储的机制。
- 扩展：在你需要一个以上的实例作为缓存之前，两者都给你大量的空间。Redis包括一些工具来帮助你超越这个范围，而memcached没有。
memcached
Memcached是一个简单的易失性缓存服务器。它允许你存储键/值对，其中的值被限制为1MB以内的字符串。
它在这方面很擅长，但这就是它的全部。你可以以极高的速度通过它们的键来访问这些值，常常使可用的网络甚至内存带宽达到饱和。
当你重新启动memcached时，你的数据就消失了。这对一个缓存来说是很好的。你不应该在那里存储任何重要的东西。
如果你需要高性能或高可用性，有第三方的工具、产品和服务可供选择。
redis
Redis可以做与memcached相同的工作，而且可以做得更好。
Redis也可以作为一个缓冲区。它也可以存储键/值对。在Redis中，它们甚至可以达到512MB。
你可以关闭持久性，它也会很乐意在重启时丢失你的数据。如果你想让你的缓存在重启后继续存在，它也可以让你这么做。事实上，这是默认的。
它的速度也超级快，经常受到网络或内存带宽的限制。
如果一个redis/memcached实例的性能不足以满足你的工作负载，redis是明确的选择。Redis包括集群支持，并配有“开箱即用”的高可用性工具（redis-sentinel），。在过去的几年里，Redis也成为了第三方工具的明显领导者。像Redis Labs、Amazon和其他公司提供了许多有用的redis工具和服务。围绕redis的生态系统要大得多。大规模部署的数量现在可能比memcached要多。
Redis的超级集合
Redis不仅仅是一个缓冲区。它是一个内存数据结构服务器。下面你会发现Redis除了像memcached那样成为一个简单的键/值缓存之外，还能做一些事情。大多数 Redis的功能是memcached无法做到的。
文件资料
Redis的文档比memcached好。虽然这可能是主观的，但它似乎一直是越来越真实的。
redis.io是一个奇妙的、易于浏览的资源。它让你在浏览器中尝试redis，甚至在文档中为你提供每个命令的实时互动例子。
现在redis的stackoverflow结果是memcached的2倍。2倍于谷歌的结果。在更多的语言中，有更多容易获得的例子。更加活跃的开发。更加活跃的客户端开发。这些测量结果可能单独并不意味着什么，但综合起来，它们描绘了一幅清晰的画面，即对redis的支持和文档更多，也更新潮。
持久化
默认情况下，redis使用一种叫做快照的机制将你的数据持久化到磁盘。如果你有足够的内存，它能够将你的所有数据写入磁盘，几乎没有性能下降。这几乎是免费的!
在快照模式下，突然的崩溃有可能会导致少量数据的丢失。如果你绝对需要确保没有数据丢失，不用担心，redis也有AOF（Append Only File）模式来支持你。在这种持久化模式下，数据可以在写入时同步到磁盘。这可能会降低最大的写入吞吐量，无论你的磁盘能写多快，但应该仍然是相当快的。
如果你需要，有许多配置选项可以对持久性进行微调，但默认值是非常合理的。这些选项使你很容易将redis设置为一个安全、冗余的数据存储场所。它是一个真实数据库。
众多的数据类型
Memcached只限于字符串，但Redis是一个数据结构服务器，可以提供许多不同的数据类型。它还提供了你需要的命令来充分利用这些数据类型。
字符串（commands）。
简单的文本或二进制值，大小可以达到512MB。这是redis和memcached唯一共享的数据类型，尽管memcached的字符串限制在1MB。
Redis为你提供了更多利用这种数据类型的工具，它提供了位操作、位级操作、浮点增减支持、范围查询和多键操作等命令。而Memcached则不支持这些。
字符串对各种使用情况都很有用，这也是为什么memcached仅用这种数据类型就相当有用的原因。
哈希（commands）。
哈希值有点像键值存储中的键值存储。它们在字符串字段和字符串值之间进行映射。使用哈希的字段>值映射比使用普通字符串的键>值映射略微节省空间。
哈希值作为一个命名空间很有用，或者当你想对许多键进行逻辑分组时。通过哈希，你可以有效地抓取所有的成员，一起过期，一起删除所有的成员，等等。对于有几个需要分组的键/值对的任何用例来说都是很好的。
散列的一个例子是在应用程序之间存储用户资料。一个以用户ID为密钥存储的redis哈希值将允许你根据需要存储关于用户的许多数据，同时将它们存储在一个单一的密钥下。使用哈希值而不是将配置文件序列化为字符串的好处是，你可以让不同的应用程序读取/写入用户配置文件中的不同字段，而不必担心一个应用程序覆盖其他应用程序所做的更改（如果你序列化过时的数据，这可能发生）。
列表（命令）
Redis 列表是字符串的有序集合。它们被优化为从列表的顶部或底部（又称：左边或右边）插入、读取或删除值。
Redis 提供了许多命令，用于利用列表，包括推送/弹出项目、在列表之间推送/弹出、截断列表、执行范围查询等命令。
列表是持久的、原子性的队列。这些队列对于工作队列、日志、缓冲区和许多其他用例来说都很好用。
集合（命令）。
集合是唯一值的无序集合。它们经过优化，可以让你快速检查一个值是否在集合中，快速添加/删除值，并衡量与其他集合的重叠情况。
这些都是很好的东西，如访问控制列表，唯一的访问者跟踪器，以及许多其他的东西。大多数编程语言都有类似的东西（通常称为Set）。这就像那样，只是分布式的。
Redis 提供了几个命令来管理集合。像添加、删除和检查集合这样明显的命令是存在的。还有一些不太明显的命令，如弹出/读取一个随机项目，以及用于与其他集合进行并集和交集的命令。
排序集（命令）。
排序集也是唯一值的集合。这些，顾名思义，是有顺序的。它们是按分数排序的，然后按词法排序。
这种数据类型被优化为按分数快速查找。获取最高、最低或介于两者之间的任何数值范围都非常快。
如果你把用户和他们的高分一起添加到一个排序的集合中，你就有了一个完美的排行榜。当有新的高分出现时，只要把他们和他们的高分再次添加到集合中，它就会重新排列你的排行榜。这对于跟踪用户的最后访问时间和谁在你的应用程序中处于活跃状态也很有帮助。
存储具有相同分数的值会使它们按词法排序（考虑按字母顺序）。这对于像自动完成功能这样的事情是很有用的。
许多经过排序的集合命令与集合的命令类似，有时还增加了一个分数参数。此外，还包括用于管理分数和按分数查询的命令。
Geo
Redis 有几个命令用于存储、检索和测量地理数据。这包括半径查询和测量点之间的距离。
从技术上讲，redis中的地理数据被存储在排序集中，所以这并不是一个真正独立的数据类型。它更像是排序集之上的一个扩展。
位图和超级日志记录器
和地理一样，这些并不是完全独立的数据类型。这些是允许你把字符串数据当作位图或超日志的命令。
位图就是我在Strings下提到的位级运算符的用途。这种数据类型是reddit最近合作艺术项目的基本构件。r/Place。
HyperLogLog允许你使用一个恒定的极小的空间来计算几乎无限的唯一值，其准确性令人震惊。只用~16KB，你就可以有效地计算出你的网站的独特访问者的数量，即使这个数字是数以百万计的。
交易和原子性
redis 中的命令是原子的，这意味着你可以确信，一旦你向 redis 写入一个值，该值对所有连接到 redis 的客户端都是可见的。不需要等待该值的传播。技术上来说，memcached也是原子的，但是redis增加了所有这些超越memcached的功能，值得注意的是，所有这些额外的数据类型和功能也是原子的，这一点令人印象深刻。
虽然与关系型数据库中的事务不太一样，但redis也有使用"乐观锁定"的transactions（WATCH/MULTI/EXEC）的。
流水线
Redis提供了一个名为"管道化"的功能。如果你有许多你想执行的Redis命令，你可以使用流水线将它们一次性地发送到Redis，而不是一次一次地发送。
通常，当你向redis或memcached执行命令时，每个命令都是一个单独的请求/响应周期。有了流水线，redis可以缓冲几个命令并一次执行，在一个回复中对所有的命令做出响应。
这可以让你在批量导入或其他涉及大量命令的操作上实现更大的吞吐量。
发布/订阅
Redis具有命令，专门用于pub/sub功能，使redis能够充当高速消息广播者。这允许单个客户端向连接到一个通道的许多其他客户端发布消息。
Redis的pub/sub功能几乎和任何工具一样好。像RabbitMQ这样的专用消息中介可能在某些方面有优势，但事实上，同一台服务器也可以为你提供持久耐用的队列和其他你的pub/sub工作负载可能需要的数据结构，Redis将经常被证明是最好的和最简单的工具。
Lua 脚本
你可以把lua脚本看作是redis自己的SQL或存储过程。它既多又少，但这个比喻基本有效。
也许你有复杂的计算，你想让redis来执行。也许你不能承受交易回滚，需要保证复杂过程的每一步都是原子化的。这些问题以及更多的问题都可以用lua脚本来解决。
整个脚本是以原子方式执行的，所以如果你能把你的逻辑融入到lua脚本中，你往往可以避免乱用乐观的锁定事务。
规模化
如上所述，redis包括对集群的内置支持，并与自己的高可用性工具捆绑在一起，称为redis-sentinel。
总结
对于任何新项目或尚未使用memcached的现有项目，我都会毫不犹豫地推荐redis而不是memcached。
上述内容可能听起来像是我不喜欢memcached。恰恰相反：它是一个强大的、简单的、稳定的、成熟的、硬化的工具。甚至在一些用例中，它比redis还要快一点。我喜欢memcached。我只是认为它对未来的发展没有什么意义。
Redis做了memcached的所有事情，而且通常做得更好。memcached的任何性能优势都是很小的，而且是针对工作负载的。还有一些工作负载，redis会更快，还有许多工作负载，redis可以做，而memcached却不能。在功能上的巨大差距面前，微小的性能差异显得微不足道，而且这两个工具都是如此快速和高效，它们很可能是你的基础设施中最后一块需要担心扩展的地方。
只有一种情况下memcached更有意义：memcached已经作为一个缓存在使用。如果你已经在用memcached进行缓存，那么继续使用它，如果它能满足你的需求。如果你打算将redis用于缓存，那么它可能不会提供足够的好处，不值得你花费时间。如果memcached不能满足你的需求，那么你可能应该转移到redis。无论你是需要扩展到memcached之外，还是需要额外的功能，都是如此。
在以下情况下使用Redis
你需要有选择地删除/淘汰缓存中的项目。(你需要这个)
你需要查询特定类型的键的能力。例如，'blog1:post:*', 'blog2:categories:xyz:post:*'。 哦，是的！这非常重要。使用这个可以有选择地使某些类型的缓存项目失效。你也可以用它来废止片段缓存、页面缓存，只废止指定类型的AR对象，等等。
持久性（你也需要这个，除非你同意你的缓存在每次重启后都要进行预热。对于很少变化的对象来说，这是非常必要的。）
使用memcached，如果
- Memcached给你带来了头疼的感觉!
- 嗯......集群？ 我不知道。如果你要走那么远，就用Varnish和Redis来缓存片段和AR对象。
根据我的经验，Redis的稳定性要比Memcached好得多。
Memcached是多线程的，而且速度很快。
Redis有很多功能，而且速度非常快，但完全限于一个核心，因为它是基于一个事件循环的。
我们两者都用。Memcached用于缓存对象，主要是减少数据库的读取负荷。Redis用于像排序集这样的东西，这对滚动时间序列数据很方便。
这个问题太长了，不能作为已经接受的答案的评论贴出来，所以我把它作为一个单独的答案。
还需要考虑的一点是，你是否希望在你的缓存实例上有一个硬性的内存上限。
由于redis是一个具有大量功能的nosql数据库，而缓存只是它可以使用的一个选项，它在需要时分配内存--你放的对象越多，它使用的内存就越多。maxmemory选项并不严格执行内存上限的使用。当你使用缓存时，键会被驱逐和过期；有可能你的键并不都是一样大的，所以会出现内部内存碎片。
默认情况下，redis 使用jemalloc内存分配器，它尽力做到内存紧凑和快速，但它是一个通用的内存分配器，它无法跟上大量分配和高速发生的对象清除的速度。正因为如此，在某些负载模式下，redis进程显然会因为内部碎片化而泄露内存。例如，如果你有一个7Gb内存的服务器，你想使用redis作为非持久性LRU缓存，你可能会发现，随着时间的推移，maxmemory设置为5Gb的redis进程会使用越来越多的内存，最终达到总内存的极限，直到内存不足的杀手介入。
memcached更适合上述场景，因为它以一种完全不同的方式管理其内存。 memcached分配了一大块内存--它所需要的一切--然后使用它自己实现的slab allocator来管理这些内存。此外，memcached努力使内部碎片保持在低水平，因为它实际上使用了每个slab的LRU算法，当LRU驱逐被考虑到对象大小时。
尽管如此，memcached在内存使用必须被强制执行和/或可预测的环境中仍然有很强的地位。我们曾尝试使用最新的稳定版redis（2.8.19）作为10-15k op/s工作负载中的非持久化LRU型memcached替代品，结果它泄露了大量的内存；同样的工作负载在一天左右的时间里，由于同样的原因，亚马逊的ElastiCache redis实例崩溃了。
maxmemory 选项没有考虑到内部内存碎片。详情请见我上面的评论--我在那里描述的问题是在启用了内存限制选项的情况下，在"Redis作为LRU缓存"页面中描述的情景下出现的。另一边，memcached使用不同的方法来避免内存碎片问题，所以它的内存限制更加"硬"。
- artyom 2015-09-07
Memcached擅长成为一个简单的键/值存储，并且擅长做key => STRING。这使得它非常适用于会话存储。
Redis很擅长做key => SOME_OBJECT。
这真的取决于你要在里面放什么。我的理解是，就性能而言，它们是相当均衡的。
另外，祝你能找到任何客观的基准，如果你找到一些，请把它们寄给我。
如果你不介意粗鲁的写作风格，Systoilet博客上的Redis vs Memcached从可用性的角度来看值得一读，但在得出任何关于性能的结论之前，请务必阅读评论中的回贴；存在一些方法论问题（单线程忙环测试），而且Redis在文章撰写后也做了一些改进。
没有一个基准链接是完整的，所以也可以在Dormondo的LiveJournal和Antirez Weblog查看一些相互冲突的基准。
Edit -- 正如Antirez所指出的，Systoilet的分析是相当欠考虑的。除了单线程的不足之外，这些基准中的大部分性能差异可以归因于客户端库而不是服务器的吞吐量。在Antirez Weblog的基准测试中，确实提出了一个更多的苹果对苹果（用同样的嘴）的比较。
我有机会在我所做的缓存代理中同时使用memcached和redis，让我与你分享我到底在哪里使用了什么，以及同一.... 背后的原因。
Redis >
1) 用于索引缓存的内容，在集群上。我有超过10亿个键分布在redis集群上，redis的响应时间相当少且稳定。
2) 基本上，它是一个键/值存储，所以在你的应用程序中，只要有类似的东西，就可以使用redis，而不需要太多麻烦。
3) Redis的持久性，故障转移和备份（AOF）将使你的工作更容易。
Memcache >
1) 是的，一个优化的内存，可以作为缓存使用。我用它来存储被频繁访问的缓存内容（50次/秒），大小小于1MB。
2) 我只为memcached分配了16GB中的2GB，而且是在我的单一内容大小>1MB的情况下。
3）当内容增长到接近极限时，我偶尔会观察到统计中更高的响应时间（Redis不是这样的）。
如果你问整体经验，Redis是绿色的，因为它很容易配置，非常灵活，具有稳定的强大功能。
此外，在这个链接上有一个基准测试结果，下面是其中的一些亮点。
希望这对你有帮助！！！。
测试。运行一些简单的基准测试。有很长一段时间，我认为自己是一个老派的犀牛，因为我主要使用memcached，认为Redis是新的孩子。
在我现在的公司，Redis被用作主要的缓存。当我钻研一些性能统计并简单地开始测试时，Redis在性能方面与MySQL相当，或者是最小的slower。
虽然Memcached很简单，但却把Redis吹得一塌糊涂，完全。它的扩展性要好得多。
- 为更大的值（需要改变板块的大小，但成功了）。
- 适用于多个并发的请求
另外，在我看来，memcached的驱逐策略实现得更好，在处理超过缓存所能处理的数据时，总体来说，平均响应时间更稳定。
一些基准测试显示，在我们的案例中，Redis的表现非常差。我相信这与许多变量有关。
- 你运行Redis的硬件的类型
- 你所存储的数据类型
- 获取和设置的数量
- 你的应用程序有多大的并发性
- 你需要数据结构存储吗？
就个人而言，我并不赞同Redis作者对并发和多线程的看法。
另一个好处是，可以非常清楚地知道memcache在缓存场景中的行为，而redis通常被用作持久性数据存储，尽管它可以被配置成与memcached一样的行为，即在达到最大容量时驱逐最近使用的项目。
我所做的一些应用同时使用这两种方法，只是为了明确我们希望数据如何表现--在memcache中的东西，我们写代码来处理它不在那里的情况--在redis中的东西，我们依靠它在那里的表现。
除此之外，Redis通常被认为在大多数使用情况下更有优势，因为它的功能更丰富，因此也更灵活。
如果我们说redis是（缓存+数据结构）的组合，而memcached只是一个缓存，那也是没有错的。
一个非常简单的测试，针对redis-2.2.2和memcached设置并获得100k唯一的键和值。两者都在linux VM（CentOS）上运行，我的客户端代码（粘贴在下面）在windows桌面上运行。
Redis
存储100000个值所需的时间是=18954ms
加载100000个值所需的时间是=18328ms
Memcached
存储100000个值所需的时间是=797ms
检索100000个值所需的时间是=38984ms
Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");
startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");
这里没有指出的一个主要区别是，Memcache在任何时候都有一个内存上限，而Redis在默认情况下没有（但可以配置为）。如果你总是想在一定时间内存储一个键/值（并且永远不会因为内存不足而驱逐它），你想用Redis。当然，你也面临着内存耗尽的问题......
如果你对性能感兴趣，Memcached会更快，只是因为Redis涉及网络（TCP调用）。另外，内部的Memcache也更快。
Redis有更多的功能，正如其他答案所提到的那样。
其余最大的原因是专业化。
Redis可以做很多不同的事情，这样做的一个副作用是开发者可能开始在同一个实例上使用很多不同的功能集。如果你在使用Redis的LRU功能进行缓存，同时使用非LRU的硬数据存储，那么就完全有可能耗尽内存。
如果你打算建立一个专门的Redis实例，只作为LRU实例来使用，以避免这种特殊情况，那么就没有任何令人信服的理由使用Redis而不是Memcached。
如果你需要一个可靠的 "永不停机 "的LRU缓存......Memcached可以满足你的要求，因为它在设计上是不可能耗尽内存的，而且特殊的功能可以防止开发者试图让它变成可能危及内存的东西。简单的关注点分离。
我们想到了Redis作为我们工作中的项目的一个负载起飞。我们认为通过在nginx中使用一个名为HttpRedis2Module或类似的模块，我们会有很棒的速度，但当用AB-test测试时，我们被证明是错误的。
也许是模块的问题，或者是我们的布局问题，但这是一个非常简单的任务，用php获取数据，然后把它塞进MongoDB，这甚至更快。我们使用APC作为缓存系统，使用php和MongoDB。这比nginx Redis模块快得多。
我的建议是自己测试，这样做会显示你的环境的结果。我们决定在我们的项目中使用Redis是不必要的，因为它没有任何意义。
Redis是更好的选择。
Redis 的优点是，
- 它有很多数据存储选项，如字符串、集、排序集、哈希值、位图等。
- 磁盘记录的持久性
- 支持存储过程(
LUA脚本)。 - 可以作为使用PUB/SUB的消息代理。
而Memcache是一个内存中的键值缓存类型的系统。
- 不支持各种数据类型的存储，如redis中的列表、集合。
- 主要的缺点是Memcache没有磁盘的持久性。
这里是由亚马逊提供的真正伟大的文章/差异。
与memcached相比，Redis是一个明显的赢家。
Memcached 只有一个加分项 它是多线程的并且速度很快。 Redis 有很多很棒的特性并且速度非常快，但仅限于一个内核。
关于Redis的观点很好，在Memcached中不支持Redis
- 快照 - 用户可以对Redis缓存进行快照，并在任何时间点坚持在二级存储上。
- 内置支持许多数据结构，如Set、Map、SortedSet、List、BitMaps等。
- 支持redis中的Lua脚本