关于Redis与Memcached的一点澄清（译）

原文：Clarifications about Redis and Memcached

译者：youngsterxyf

译注：本文为Redis的作者所写

如果你了解我，就会知道我并不是那种认为竞品是一件坏事的人。实际上我喜欢用户有选择的空间，因此我很少做将Redis与其他技术做对比这类事情。

然而，为了选择正确的方案，用户必须获取正确的知识，这一点也是理所应当的。

本文的起因是读了Mike Perham写的一篇博文，你也许知道他是Sidekiq这一流行程序库的作者，Sidekiq又恰好使用Redis做后端。因此我毫不认为Mike是一个“反对”Redis的人。但在博文（你可以在 http://www.mikeperham.com/2015/09/24/storing-data-with-redis/ 找到这篇博文）中，他陈述到：要用缓存，“你可能应该选择Memcached（而不是Redis）”。这样看来，Mike确实简单地相信Redis不适合用做缓存，在文章中他是这样论述的：

• 1) Memcached专为缓存而设计
• 2) 它根本不会有磁盘I/O操作
• 3) 它是多线程的，在多核上能线性扩展到每秒处理100,000个请求

我会一一辩驳以上陈述，之后会提供进一步的信息，这些信息在上面的句子中并没有得到表达，但在我看来与缓存用户及用例更加相关。

Memcached专为缓存而设计：我会跳过这个，因为这并不是一个论点。我同样可以说“Redis专为缓存而设计”。因此，就这一点而言，它们是一样的，我们接着来看下一个论点。

它根本不会有磁盘I/O操作：使用Redis时，你可以按需求禁用磁盘I/O，所有操作就是纯内存的了。此外，若你确实需要，可以只在重启Redis之时持久化数据库，例如：使用“SHUTDOWN SAVE”命令。再怎么说，即使你根本不使用Redis持久化功能，它也是一个附加值。

它是多线程的：确实如此。我的目标是把Redis的I/O线程化（像Memcached那样，从根本上说数据访问本身不是线程化的）。然而，Redis，特别是使用流水线（pipeling）模式后，每个线程每秒能处理超大量的请求（使用密集的流水线，通常能达到每秒50万左右；不使用流水线，也能达到每秒10万左右）。在普通的缓存场景中 - 每个Redis实例是一样的、角色为主、禁用磁盘操作、分区由客户端决定（像“Memcached分区模型”那样） - 每个系统上运行多个Redis进程并不可怕。一旦你这样做，得到的就是一套无共享多线程的设置，那么关键看的是单个线程能够处理的操作量了。上一次我检验 Redis时，每个线程至少是和Memached一样快的。内部实现随着时间在改变，因此如今最新版可能有所出入，但我敢打赌两者的性能是相近的，因为它们都竭尽所能利用了能够使用的资源。Memcached的多线程仍然是个优势，因为它让一切更易于使用和管理，但我认为这不是关键性的部分。

再说一点。Mike在谈及每秒执行的操作时，并未说明操作的 *质量*。在Redis与Memached这类系统中，相比真正地获取内存数据结构中的数据，命令分发和I/O的代价是主要的。因此本质上在Redis中执行一个简单的GET、SET或一个复杂操作如ZRANK操作，其代价基本是相同的。但是从应用层的角度来看，通过复杂操作能节省很多工作。也许无需分5 次获取缓存数据，你只要发送一个简短的Lua脚本就能搞定。因此这两个系统实际的“可扩展性”有许多维度，你能得到是其中之一。

Mike关注的几点问题，我认为唯一有根据的是多线程那个，如果我们将特殊用例下的Redis看做是Memcached的替代品，执行多个 Redis进程也能反驳“Memcached多线程更好”这个观点，或者简单地执行一个Redis进程也行，因为做Memcached那样的操作要想打满一个线程是非常非常难的。

真正的区别

现在是时候谈论两个系统之间的真正区别了。

• 内存效率

这一点Memcached曾比Redis做得好。在一个被设计为用字典化字符串存储普通字符串的系统中，更好地利用内存相对会更简单。这一区别并不显著，而且大约有5年我没去检验这一点了，但曾经是值得注意的。

然而，如果我们考虑一个长期运行的进程的内存效率，事情就有些不同了。具体细节请读下一节。

但是在真正评估内存效率时，你应该记得考虑：Redis中特殊编码的小型聚合值内存效率非常高。例如：小整数集合在内存存储为一个8、16、32或64位整数的数组，当需要检查某些整数是否存在时，对数级时间就能访问到，因为这个数组是有序的，因为可以使用二分查找。

当你使用哈希来存储对象而不是借助JSON时，同样如此。因此，真正的内存效率必须基于手头的应用案例来评估。

• Redis LRU vs Slab内存分配器

从内存利用的角度来看，Memcached并不完美。如果你恰好有个应用随着时间会改变缓存数据的尺寸大小，很可能会导致严重的内存碎片问题，而唯一的解决方法就是重启应用。从这一视角来看，Redis对内存的利用不会变化莫测。

此外，Redis的LRU最近优化了很多，现在非常接近真正的LRU。进一步的信息可阅读：http://redis.io/topics/lru-cache。如果我没理解错的话，Memcached的LRU依旧是根据它的slab分配器来判断数据过期的，因此有时其行为与真正的LRU相差甚远，但我希望这方面的专家能够针对这个问题说点什么。如果你想测试Redis的LRU，在最近几个版本的Redis中可以使用redis-cli的LRU测试模式。

• 智能缓存

如果你想把Redis用作缓存，并且像Memcached那样使用，那你就真的要错失一些东西了。在我看来，这是Mike那篇博文中的最大错误。越来越多的人从Memcached切换到Redis，是因为他们发现可以以更有用的方式来表现缓存数据。如何保持只缓存某个东西的最新N项数据？使用“脱帽”列表（原文为：capped list）。想获取一个缓存的流行指数？使用一个有序集合，等等。

• 持久化和复制

若你需要，那它们就是重要的优势。例如：使用这一模型扩展高负载的缓存读操作就非常简单；基于持久化 - 按期快照缓存数据 - 重启服务而不丢缓存数据也很简单；诸如此类等等。但是对有些用法来说，这两个特性确实无关紧要。这里我想表达的是存在一些“纯缓存”的应用案例，其中持久化和复制也很重要。

• 可观测性

Redis提供了很多方式以便于观测Redis运行时的行为状态。它提供大量内部度量的详细报告，你可以扫描数据集，观察对象的有效期。可以调优LRU算法。可以为客户端连接命名并使用CLIENT LIST来查看关于它们的报告。可以使用MONITOR命令来调试你的应用，以及其他高级事项。我相信这是一大优势。

• Lua脚本编程能力

我相信在很多缓存应用案例中，Lua脚本编程能力都是一大助力。例如：如果你有一个JSON缓存数据块，使用一个Lua命令可以抽取其中某个字段并将其返回给客户端，而不需要传输所有东西（从概念上来说，直接使用Redis哈希来表现对象，也可以做到）。

结论

Memcached是一个伟大的软件，我多次阅读其源码，对于我们产业来说，它是一个革命，你应该自己查明对你来说，相比 Redis，Memcached是否是更好的选择。然而，一切事物都必须如实评估。读到Mike的报告或这些年来读到的类似报告都让我有些恼怒了，所以我决定亮一亮自己的观点。如果你发现有些事情事实上我说得不对，请联系我，我会以“校订”一节来更新这篇博文。