我们正在使用带有 Redis 服务器的 Ruby 网络应用程序进行缓存。是否有必要改为测试Memcached？
什么会给我们带来更好的性能？ Redis 和 Memcached 之间有什么优缺点？
需要考虑的要点：
【问题讨论】：
标签： caching web-applications memcached redis
我们将 Redis 视为我们工作中项目的负载起飞。我们认为通过在 nginx 中使用名为 HttpRedis2Module 的模块或类似的模块，我们的速度会非常快，但是当使用 AB-test 进行测试时，我们被证明是错误的。
也许模块坏了或者我们的布局，但这是一个非常简单的任务，使用 php 获取数据然后将其填充到 MongoDB 中更快。我们使用 APC 作为缓存系统以及 php 和 MongoDB。它比nginx Redis 模块快得多。
我的建议是自己进行测试，这样做会显示适合您环境的结果。我们认为在我们的项目中没有必要使用 Redis，因为它没有任何意义。
【讨论】：
Here 是亚马逊提供的非常棒的文章/差异
与 memcached 相比，Redis 是明显的赢家。
Memcached 只加一分 它是多线程的，速度很快。 Redis 有很多很棒的功能，而且速度非常快，但仅限于一个核心。
关于 Redis 的要点，Memcached 不支持这些要点
【讨论】：
Redis 更好。
Redis 的优点是，
LUA 脚本）支持而Memcache 是内存中的键值缓存类型系统。
【讨论】：
如果您对性能感兴趣，Memcached 会更快，即使因为 Redis 涉及网络（TCP 调用）。在内部，Memcache 也更快。
Redis 具有其他答案中提到的更多功能。
【讨论】：
针对 redis-2.2.2 和 memcached 设置和获取 100k 唯一键和值的非常简单的测试。两者都在 linux VM(CentOS) 上运行，我的客户端代码（粘贴在下面）在 windows 桌面上运行。
Redis
存储 100000 个值所需的时间为 = 18954 毫秒
加载 100000 个值所需的时间为 = 18328 毫秒
内存缓存
存储 100000 个值所需的时间为 = 797 毫秒
检索 100000 个值所需的时间为 = 38984 毫秒
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");
【讨论】：
2017 年 6 月 3 日更新
Redis 比 memcached 更强大、更流行且支持更好。 Memcached 只能做 Redis 能做的事情的一小部分。 Redis 更好，即使它们的功能重叠。
对于任何新事物，请使用 Redis。
这两个工具都是强大、快速的内存数据存储，可用作缓存。两者都可以通过缓存数据库结果、HTML 片段或其他任何生成成本可能很高的东西来帮助加速您的应用程序。
当用于同一事物时，以下是它们使用原始问题的“要考虑的要点”进行比较的方式：
Memcached 是一个简单的易失性缓存服务器。它允许您存储键/值对，其中值被限制为不超过 1MB 的字符串。
它擅长于此，但仅此而已。您可以通过它们的键以极高的速度访问这些值，这通常会导致可用网络甚至内存带宽饱和。
当您重新启动 memcached 时，您的数据就消失了。这对于缓存来说很好。你不应该在那里存放任何重要的东西。
如果您需要高性能或高可用性，可以使用第三方工具、产品和服务。
Redis 可以完成与 memcached 相同的工作，并且可以做得更好。
Redis 也可以act as a cache。它也可以存储键/值对。在 redis 中，它们甚至可以达到 512MB。
您可以关闭持久性，它也会很高兴在重新启动时丢失您的数据。如果您希望您的缓存在重新启动后仍然存在，那么您也可以这样做。事实上，这是默认设置。
它也非常快，但通常受到网络或内存带宽的限制。
如果一个 redis/memcached 实例的性能不足以满足您的工作负载，那么 redis 是明确的选择。 Redis 包括cluster support 并带有高可用性工具 (redis-sentinel) 就在“盒子里”。在过去的几年里，redis 也已成为 3rd 方工具的明显领导者。 Redis Labs、Amazon 等公司提供许多有用的 redis 工具和服务。 redis 周围的生态系统要大得多。大规模部署的数量现在可能比 memcached 多。
Redis 不仅仅是一个缓存。它是一个内存数据结构服务器。您将在下面快速了解 Redis 可以做的事情，而不仅仅是像 memcached 这样的简单键/值缓存。 大部分 redis 的功能是 memcached 无法做到的。
Redis 比 memcached 有更好的文档记录。虽然这可能是主观的，但似乎越来越真实。
redis.io 是一个很棒的易于导航的资源。它可以让您try redis in the browser 甚至为您提供文档中每个命令的实时交互式示例。
现在 redis 的 stackoverflow 结果是 memcached 的 2 倍。 2 倍的 Google 结果。更多语言的更易于访问的示例。更积极的发展。更积极的客户开发。这些测量值单独可能意义不大，但结合起来，它们清楚地描绘了对 redis 的支持和文档更强大和更新的清晰画面。
默认情况下，redis 使用一种称为快照的机制将数据持久化到磁盘。如果您有足够的 RAM 可用，它能够将所有数据写入磁盘而几乎不会降低性能。它几乎是免费的！
在快照模式下，突然崩溃可能会导致少量数据丢失。如果您绝对需要确保不会丢失任何数据，请不要担心，redis 也支持 AOF（仅附加文件）模式。在这种持久性模式下，数据可以在写入时同步到磁盘。这可以将最大写入吞吐量降低到磁盘可以写入的速度，但仍然应该很快。
如果需要，有许多配置选项可以微调持久性，但默认设置非常合理。这些选项可以轻松地将 redis 设置为存储数据的安全、冗余的地方。这是一个真实的数据库。
Memcached 仅限于字符串，但 Redis 是一种数据结构服务器，可以提供许多不同的数据类型。它还提供了充分利用这些数据类型所需的命令。
最大为 512MB 的简单文本或二进制值。这是 redis 和 memcached 共享的唯一数据类型，尽管 memcached 字符串限制为 1MB。
Redis 通过提供用于按位运算、位级操作、浮点递增/递减支持、范围查询和多键操作的命令，为您提供了更多利用此数据类型的工具。 Memcached 不支持这些。
字符串对于各种用例都很有用，这就是 memcached 单独用于这种数据类型的原因。
哈希有点像键值存储中的键值存储。它们在字符串字段和字符串值之间映射。使用散列的字段->值映射比使用常规字符串的键->值映射更节省空间。
哈希可用作命名空间，或者当您想要对许多键进行逻辑分组时。使用哈希，您可以有效地获取所有成员、将所有成员一起过期、一起删除所有成员等。非常适合您有多个需要分组的键/值对的任何用例。
哈希的一个示例用途是在应用程序之间存储用户配置文件。使用用户 ID 作为键存储的 redis 哈希将允许您根据需要存储尽可能多的用户数据位，同时将它们存储在单个键下。使用哈希而不是将配置文件序列化为字符串的优点是，您可以让不同的应用程序读取/写入用户配置文件中的不同字段，而不必担心一个应用程序会覆盖其他应用程序所做的更改（如果您序列化过时，可能会发生这种情况数据）。
Redis 列表是有序的字符串集合。它们针对从列表的顶部或底部（又名：左侧或右侧）插入、读取或删除值进行了优化。
Redis 提供了许多commands 用于利用列表，包括推送/弹出项目的命令、列表之间的推送/弹出、截断列表、执行范围查询等。
列表是非常持久的原子队列。它们非常适用于作业队列、日志、缓冲区和许多其他用例。
集合是唯一值的无序集合。它们经过优化，可让您快速检查集合中是否存在值、快速添加/删除值以及测量与其他集合的重叠。
这些非常适合访问控制列表、唯一访问者跟踪器和许多其他内容。大多数编程语言都有类似的东西（通常称为 Set）。就是这样，只是分布式的。
Redis 提供了几个commands 来管理集合。存在诸如添加、删除和检查集合之类的明显操作。诸如弹出/读取随机项目以及与其他集合执行联合和交集的命令等不太明显的命令也是如此。
Sorted Sets 也是唯一值的集合。顾名思义，这些是有序的。它们按分数排序，然后按字典顺序排列。
此数据类型针对按分数快速查找进行了优化。获取最高值、最低值或介于两者之间的任何值范围都非常快。
如果您将用户连同他们的高分一起添加到排序集中，您就拥有了一个完美的排行榜。当新的高分出现时，只需将他们的高分再次添加到集合中，它就会重新排列您的排行榜。也非常适合跟踪用户上次访问的时间以及谁在您的应用程序中处于活动状态。
存储具有相同分数的值会使它们按字典顺序排列（按字母顺序排列）。这对于自动完成功能等功能很有用。
许多排序集commands 类似于集的命令，有时带有额外的分数参数。还包括用于管理分数和按分数查询的命令。
Redis 有几个commands 用于存储、检索和测量地理数据。这包括半径查询和测量点之间的距离。
从技术上讲，redis 中的地理数据存储在排序集中，因此这并不是真正独立的数据类型。它更像是对有序集合的扩展。
与地理一样，这些不是完全独立的数据类型。这些命令允许您将字符串数据视为位图或超级日志。
位图是我在Strings 下引用的位级运算符的用途。这种数据类型是 reddit 最近合作艺术项目的基本构建块：r/Place。
HyperLogLog 允许您使用恒定的极小空间以惊人的准确性计算几乎无限的唯一值。仅使用大约 16KB，您就可以有效地统计您网站的唯一身份访问者的数量，即使该数字以百万计。
redis 中的命令是原子的，这意味着您可以确定，只要将值写入 redis，该值对连接到 redis 的所有客户端都是可见的。无需等待该值传播。从技术上讲，memcached 也是原子的，但是随着 redis 在 memcached 之外添加所有这些功能，值得注意且令人印象深刻的是，所有这些额外的数据类型和特性也是原子的。
虽然与关系数据库中的事务不太一样，但 redis 也有使用“乐观锁定”的transactions (WATCH/MULTI/EXEC)。
Redis 提供了一个名为“pipelining”的功能。如果您有许多要执行的 redis 命令，您可以使用流水线将它们一次性发送到 redis，而不是一次一个。
通常，当您对 redis 或 memcached 执行命令时，每个命令都是一个单独的请求/响应周期。通过流水线，redis 可以缓冲多个命令并同时执行它们，在一个回复中响应所有命令的所有响应。
这可以让您在批量导入或其他涉及大量命令的操作时获得更大的吞吐量。
Redis 有commands 专用于pub/sub functionality，允许redis 充当高速消息广播器。这允许单个客户端向连接到通道的许多其他客户端发布消息。
Redis 的发布/订阅功能与几乎所有工具一样。像RabbitMQ 这样的专用消息代理可能在某些领域具有优势，但事实上，同一台服务器还可以为您提供持久的持久队列和您的发布/订阅工作负载可能需要的其他数据结构，Redis 通常会被证明是最好和最简单的工具。
您可以将lua scripts 想象成redis 自己的SQL 或存储过程。既多又少，但这个类比大多是有效的。
也许您有想要 redis 执行的复杂计算。也许您不能让您的事务回滚，并且需要保证复杂过程的每一步都将自动发生。这些问题以及更多问题都可以通过 lua 脚本来解决。
整个脚本以原子方式执行，因此如果您可以将逻辑放入 lua 脚本中，您通常可以避免与乐观锁定事务混淆。
如上所述，redis 包含对集群的内置支持，并与它自己的名为 redis-sentinel 的高可用性工具捆绑在一起。
我会毫不犹豫地为任何新项目或尚未使用 memcached 的现有项目推荐 redis 而不是 memcached。
上面的内容听起来好像我不喜欢 memcached。相反：它是一个强大、简单、稳定、成熟和硬化的工具。甚至在一些用例中它比 redis 快一点。我喜欢内存缓存。我只是认为这对未来的发展没有多大意义。
Redis 完成了 memcached 所做的一切，而且通常做得更好。 memcached 的任何性能优势都是次要的，并且是特定于工作负载的。还有一些工作负载 redis 会更快，还有更多的工作负载 redis 可以做而 memcached 根本做不到。面对功能上的巨大鸿沟，微小的性能差异似乎微不足道，而且这两种工具都非常快速和高效，它们很可能是您的基础架构中您永远不必担心扩展的最后一块。
只有一种情况下 memcached 更有意义：memcached 已经用作缓存。如果您已经使用 memcached 进行缓存，那么如果它满足您的需求，请继续使用它。迁移到 redis 可能不值得付出努力，如果您打算将 redis 仅用于缓存，它可能无法提供足够的好处，不值得您花时间。如果 memcached 不能满足您的需求，那么您可能应该转向 redis。无论您需要超越 memcached 还是需要其他功能，这都是正确的。
【讨论】：
我有机会在我从事的缓存代理中同时使用 memcached 和 redis，让我分享一下我到底在哪里使用了相同的内容和原因......
Redis >
1) 用于在集群上索引缓存内容。我有超过十亿个键分布在 redis 集群中，redis 响应时间非常短且稳定。
2) 基本上，它是一个键/值存储，所以无论在你的应用程序中哪里有类似的东西，都可以使用 redis 来解决很多问题。
3) Redis 持久性、故障转移和备份 (AOF) 将使您的工作更轻松。
内存缓存 >
1) 是的，可以用作缓存的优化内存。我用它来存储被频繁访问的缓存内容（每秒 50 次），大小小于 1 MB。
2) 当我的单个内容大小为 >1MB 时，我也只为 memcached 分配了 16 GB 中的 2GB。
3) 随着内容的增长接近极限，我偶尔会在统计数据中观察到更高的响应时间（redis 不是这种情况）。
如果您要求整体体验，Redis 非常环保，因为它易于配置、非常灵活且具有稳定的强大功能。
此外，link 提供了一个基准测试结果，以下是相同的几个亮点，
希望这会有所帮助！
【讨论】：
剩下的最大原因是专业化。
Redis 可以做很多不同的事情，其中一个副作用是开发人员可能会开始在同一个实例上使用很多不同的功能集。如果您将 Redis 的 LRU 功能用于非 LRU 的硬数据存储旁边的缓存，则完全有可能耗尽内存。
如果您要设置一个专用的 Redis 实例，仅用作 LRU 实例以避免这种特殊情况，那么实际上没有任何令人信服的理由使用 Redis 而不是 Memcached。
如果您需要一个可靠的“永不失效”的 LRU 缓存...Memcached 可以满足您的需求，因为它在设计上不可能耗尽内存，而且专门的功能阻止了开发人员尝试使其成为可能的东西危及那个。简单的关注点分离。
【讨论】：
测试。运行一些简单的基准测试。很长一段时间以来，我都认为自己是老派犀牛，因为我主要使用 memcached，并认为 Redis 是新生事物。
在我目前的公司中，Redis 被用作主缓存。当我深入研究一些性能统计数据并开始测试时，Redis 在性能方面与 MySQL 相当或慢。
Memcached，虽然简单，却彻底将 Redis 彻底淘汰。它的扩展性更好：
此外，在我看来，memcached 驱逐策略实施得更好，从而在处理比缓存能够处理的更多数据时总体上更稳定的平均响应时间。
一些基准测试显示，在我们的案例中，Redis 的性能非常差。我认为这与许多变量有关：
就我个人而言，我不同意 Redis 作者对并发和多线程的看法。
【讨论】：
没错，如果说redis是（缓存+数据结构）的组合，而memcached只是一个缓存。
【讨论】：
这太长了，不能作为评论发布到已经接受的答案，所以我把它作为一个单独的答案
还要考虑的一件事是您是否希望缓存实例具有硬性的内存上限。
由于 redis 是一个具有大量功能的 nosql 数据库，而缓存只是它可以使用的一个选项，它会根据需要分配内存 - 您放入其中的对象越多，它使用的内存就越多。 maxmemory 选项不严格强制使用内存上限。当您使用缓存时，密钥会被逐出并过期；很可能您的密钥大小不一样，因此会发生内部内存碎片。
默认情况下，redis 使用jemalloc 内存分配器，它尽最大努力实现内存紧凑和快速，但它是一个通用的内存分配器，它无法跟上大量分配和对象清除的速度速度。因此，在某些加载模式下，redis 进程显然会由于内部碎片而泄漏内存。例如，如果您有一个具有 7 Gb RAM 的服务器，并且您想使用 redis 作为非持久 LRU 缓存，您可能会发现随着时间的推移将maxmemory 设置为 5Gb 的 redis 进程会使用越来越多的内存，最终达到总RAM 限制，直到内存不足的杀手干扰。
memcached 更适合上述场景，因为它以完全不同的方式管理其内存。 memcached 分配一大块内存——它需要的一切——然后使用它自己实现的slab allocator 自行管理这块内存。此外，memcached 努力将内部碎片保持在较低水平，因为它实际上是uses per-slab LRU algorithm，当 LRU 驱逐是在考虑对象大小的情况下完成的。
话虽如此，memcached 在内存使用必须强制执行和/或可预测的环境中仍然占有重要地位。我们尝试在 10-15k op/s 的工作负载中使用最新的稳定版 redis (2.8.19) 作为基于 LRU 的非持久性 memcached 替代品，但它泄漏了很多内存；由于相同的原因，相同的工作负载在一天左右的时间内使 Amazon 的 ElastiCache redis 实例崩溃。
【讨论】：
maxmemory 选项不考虑内部内存碎片。有关详细信息，请参阅我上面的评论——我所描述的问题是在启用内存限制选项的“Redis 作为 LRU 缓存”页面中描述的场景下看到的。另一方面，memcached 使用不同的方法来避免内存碎片问题，因此它的内存限制更加“硬”。
Memcached 是多线程的，速度很快。
Redis 有很多功能，速度非常快，但完全限于一个核心，因为它基于事件循环。
我们两者都用。 Memcached 用于缓存对象，主要是减少数据库的读取负载。 Redis 用于诸如排序集之类的东西，它们可以方便地汇总时间序列数据。
【讨论】：
这里没有指出的一个主要区别是 Memcache 在任何时候都有内存上限，而 Redis 默认情况下没有（但可以配置为）。如果您总是想在一定时间内存储一个键/值（并且永远不会因为内存不足而将其驱逐），那么您希望使用 Redis。当然，你也冒着内存不足的风险……
【讨论】：
如果您不介意粗俗的写作风格，从可用性的角度来看，Systoilet 博客上的Redis vs Memcached 值得一读，但在对性能做出任何结论之前，请务必仔细阅读 cmets 中的内容；有一些方法学问题（单线程忙循环测试），并且 Redis 自从写了这篇文章以来也做了一些改进。
没有任何基准链接是完整的而不会使事情有点混乱，所以还请查看Dormondo's LiveJournal 和the Antirez Weblog 上的一些冲突基准。
编辑 -- 正如 Antirez 指出的那样，Systoilet 分析的构思相当糟糕。即使超出了单线程的不足，这些基准测试中的大部分性能差异也可以归因于客户端库而不是服务器吞吐量。 the Antirez Weblog 的基准确实提供了更多的苹果对苹果（同一张嘴）的比较。
【讨论】：
如果
使用Redis您需要有选择地删除/过期缓存中的项目。 （你需要这个）
您需要能够查询特定类型的键。等式。 'blog1:posts:*'、'blog2:categories:xyz:posts:*'。哦耶！这个非常重要。使用它可以选择性地使某些类型的缓存项无效。您还可以使用它来使片段缓存、页面缓存、仅给定类型的 AR 对象等无效。
持久性（您也需要它，除非您对每次重启后都必须预热缓存感到满意。对于很少更改的对象非常重要）
如果
使用memcached根据我的经验，Redis 的稳定性比 Memcached 好得多
【讨论】：
另一个好处是可以非常清楚地知道 memcache 在缓存场景中的行为方式，而 redis 通常用作持久性数据存储，尽管它可以配置为像 memcached 一样，也就是驱逐最近最少使用的项目它达到最大容量。
我使用过的一些应用程序使用这两种方法只是为了明确我们希望数据的行为方式 - 内存缓存中的内容，我们编写代码来处理不存在的情况 - redis 中的内容，我们依赖它就在那里。
除此之外，Redis 通常被认为在大多数用例中更出色，因为它功能更丰富，因此更灵活。
【讨论】：
Memcached 擅长做简单的 key/value 存储，擅长做 key => STRING。这使得它非常适合会话存储。
Redis 擅长做 key => SOME_OBJECT。
这真的取决于你要在那里放什么。我的理解是，就性能而言，它们相当平均。
也祝你好运找到任何客观的基准，如果你确实找到了一些，请将它们发送给我。
【讨论】：