回击就代表输了?!
今年年中,一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 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 的方式。“在单台机器上运行集群,只是为了能够使用超过 1 个 core" 是额外的复杂性,人们只有在别无选择的情况下才会这样做,如果竞争者无论有多少个 core 都能 “just works",那么最好能有更容易的设置。
还有人表示,这篇文章是 Redis 团队在有礼貌地否认“Dragonfly 是最快的缓存系统”,但更多网友表示,Redis 发文章进行“回击”,就已经代表他们的营销部门输了:
“Redis 投入如此多的工程精力来写这么一篇文章,还对 Reids/Dragonfly 进行了基准测试,这是对 Dragonfly 的极大赞美。”
“我很高兴 Redis 发了这篇文章,因此我必须要去了解一下 Dragonfly,它看起来很棒。”
Redis 博客文章翻译:
作为一项基础性技术,每隔段时间总有人跳出来,想要替 Redis 换套新架构。
几年之前,KeyDB 就提出了这类方案,而最近亮相的 Dragonfly 则声称是速度最快的 Redis 兼容型内存数据存储系统。没错,这类方案的涌现当然带来了不少值得关注和讨论的有趣技术 / 思路。在 Redis,我们也喜欢迎接挑战,重新审视 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 实例,我们可以:
将每个 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。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CCNCmJLI-1660734122518)(https://upload-images.jianshu.io/upload_images/28366454-c2ef7b5a94e4722a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
单 GET 通道延迟低于 1 毫秒:
OSS Redis:每秒 443 万次操作,其中延迟平均值与第 50 百分位值均达到亚毫秒级别。平均客户端延迟为 0.383 毫秒。
Dragonfly 声称每秒 400 万次操作:
我们成功重现至每秒 380 万次操作,平均客户端延迟为 0.390 毫秒
Redis 对 Dragonfly——Redis 吞吐量比 Dragonfly 声称的结果高出 10%,比我们成功重现的 Dragonfly 结果高 18%。
30 条 GET 通道:
OSS Redis:每秒 2290 万次操作,客户端平均延迟为 2.239 毫秒
Dragonfly 声称每秒可达 1500 万次操作:
我们成功重现了每秒 1590 万次操作,客户端平均延迟为 3.99 毫秒
Redis 对 Dragonfly——与 Dragonfly 的重现结果和声称结果相比,Redis 分别胜出 43% 和 52%
单 SET 通道延迟低于 1 毫秒:
OSS Redis:每秒 474 万次操作,延迟平均值与第 50 百分位值均达到亚毫秒级。客户端平均延迟为 0.391 毫秒
Dragonfly 声称每秒 400 万次操作:
我们成功重现了每秒 400 万次操作,客户端平均延迟为 0.500 毫秒
Redis 对 Dragonfly——与 Dragonfly 的重现结果和声称结果相比,Redis 均胜出 19%
30 条 SET 通道:
OSS Redis:每秒 1985 万次操作,客户端平均延迟为 2.879 毫秒
Dragonfly 声称每秒 1000 万次操作:
我们成功重现了每秒 1400 万次操作,客户端平均延迟为 4.203 毫秒
Redis 对 Dragonfly——与 Dragonfly 的重现结果和声称结果相比,Redis 分别胜出 42% 和 99%
用于各变体的 memtier_benchmark 命令:
单 GET 通道延迟低于 1 毫秒
30 条 GET 通道
单 SET 通道延迟低于 1 毫秒
30 条 SET 通道
在本次比较测试中,我们在客户端(用于运行 memtier_benchmark)和服务器(用于运行 Redis 和 Dragonfly)使用了相同的虚拟机类型,具体规格为: