今年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 Dragonfly，用 C/C++ 编写，基于 BSL 许可（Business Source License）分发。
根据过往的基准测试结果来看， Dragonfly 可能是世界上最快的内存存储系统，它提供了对 Memcached 和 Redis 协议的支持，但能够以更高的性能进行查询，运行时内存消耗也更少。与 Redis 相比，Dragonfly 在典型工作负载下实现了 25 倍的性能提升；单个 Dragonfly 服务器每秒可以处理数百万个请求；在 5GB 存储测试中，Dragonfly 所需的内存比 Redis 少 30%。
作为一个开源软件，Dragonfly 在短短两个月获得了 9.2K GitHub 星，177 个 fork 分支。虽然这些年，涌现了不少类似的 Redis 兼容型内存数据存储系统，例如 KeyDB、Skytable，但是都没能像这次这么“轰动”。毕竟 Redis 诞生了十多年，这时从头开始设计一个缓存系统，可以抛弃 历史 包袱，更好地利用资源。
为回击新冒头的 Dragonfly，Redis 的联合创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 联合发布了一篇名为《13 年后，Redis 是否需要新的架构》的文章。
在文章中，他们特地给出了自认更加公平的 Redis 7.0 vs. Dragonfly 基准测试结果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及一些有关 Redis 架构的观点和思考，以证明 “为什么 Redis 的架构仍然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。
虽然他们强调 Redis 架构仍然是同类最佳，但也没法忽视 Dragonfly 这些新软件提供的一些新鲜、有趣的想法和技术，Redis 表示其中的一些甚至有可能在未来进入 Redis（比如已经开始研究的 io_uring 、更现代的 dictionaries、更有策略地使用线程等）。
另外，Redis 指出 Dragonfly 基准测试的比较方法 “不能代表 Redis 在现实世界中的运行方式” 。对此，Reddit 上有网友反驳称：
还有人表示，这篇文章是 Redis 团队在有礼貌地否认“Dragonfly 是最快的缓存系统”，但更多网友表示，Redis 发文章进行“回击”，就已经代表他们的营销部门输了：
我们当然一直在寻求为 Redis 提升性能、扩充功能的创新方向，但这里我们想聊聊自己的观点和思考，阐释 Redis 时至今日为何仍是最出色的实时内存数据存储（包括缓存、数据库以及介于二者之间的一切）方案之一。
接下来，我们将重点介绍 Redis 对于速度和架构差异的观点，再以此为基础做出比较。在文章的最后，我们还会提供基准测试结果、与 Dragonfly 项目的详尽性能比较信息，欢迎大家自行对比参考。
Dragonfly 基准测试其实是将独立单进程 Redis 实例（只能使用单一核心）与多线程 Dragonfly 实例（可以使用虚拟机 / 服务器上的全部可用核心）进行比较。很明显，这样的粗暴比较并不能代表 Redis 在现实场景下的运行状态。作为技术构建者，我们希望更确切地把握自有技术同其他方案间的差异，所以这里我们做了一点公平性调整：将具有 40 个分片的 Redis 7.0 集群（可使用其中的大部分实例核心）与 Dragonfly 团队在基准测试中使用的最大实例类型（AWS c4gn.16xlarge）进行性能比较。
在这轮测试中，我们看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而这还仅仅只用到全部 64 个 vCore 中的 40 个。
在我们看来，每一位多线程项目的开发者在立项之前，都会根据以往工作中经历过的痛点来指导架构决策。我们也承认，在多核设备上运行单一 Redis 进程（这类设备往往提供几十个核心和数百 GB 内存）确实存在资源无法充分利用的问题。但 Redis 在设计之初也确实没有考虑到这一点，而且众多 Redis 服务商已经拿出了相应的解决方案，借此在市场上占得一席之地。
Redis 通过运行多个进程（使用 Redis 集群）实现横向扩展，包括在单一云实例背景下也是如此。在 Redis 公司，我们进一步拓展这个概念并建立起 Redis Enterprise。Redis Enterprise 提供管理层，允许用户大规模运行 Redis，并默认启用高可用性、即时故障转移、数据持久与备份等功能。
下面，我们打算分享幕后使用的一些原则，向大家介绍我们如何为 Redis 的生产应用设计良好的工程实践。
通过在每个虚拟机上运行多个 Redis 实例，我们可以：
我们不允许单一 Redis 进程的大小超过 25 GB（运行 Redis on Flash 时上限为 50 GB）。如此一来，我们就能：
以横向扩展的方式灵活运行内存数据存储，是 Redis 获得成功的关键。下面来看具体原因：
我们仍然欣赏由社区提出的种种有趣思路和技术方案。其中一部分有望在未来进入 Redis（我们已经开始研究 io_uring、更现代的字典、更丰富的线程使用策略等）。但在可预见的未来，我们不会放弃 Redis 所坚守的无共享、多进程等基本架构原则。这种设计不仅具备最佳性能、可扩展性和弹性，同时也能够支持内存内实时数据平台所需要的各类部署架构。
附录：Redis 7.0 对 Draonfly 基准测试细节
版本：
目标：
客户端配置：
资源利用与配置优化：
最后，我们还发现 Redis 和 Dragonfly 都不受网络每秒数据包或传输带宽的限制。我们已经确认在 2 个虚拟机间（分别作为客户端和服务器，且均使用 c6gn.16xlarge 实例）使用 TCP 传递约 300 B 大小的数据包负载时，可以让每秒数据包传输量达到 1000 万以上、传输带宽超过 30 Gbps。
单 GET 通道延迟低于 1 毫秒：
30 条 GET 通道：
单 SET 通道延迟低于 1 毫秒：
30 条 SET 通道:
用于各变体的 memtier_benchmark 命令：
单 GET 通道延迟低于 1 毫秒
30 条 GET 通道
单 SET 通道延迟低于 1 毫秒
30 条 SET 通道
在本次比较测试中，我们在客户端（用于运行 memtier_benchmark）和服务器（用于运行 Redis 和 Dragonfly）使用了相同的虚拟机类型，具体规格为：
参考链接：
https://redis.com/blog/redis-architecture-13-years-later/
https://www.reddit.com/r/programming/comments/wiztpx/redis_hits_back_at_dragonfly/
原文链接：https://www.infoq.cn/article/AlF5NIhHdskayl0MTyQG