当前位置：首页 > news >正文

性能比拼: Redis vs Dragonfly

news 来源：原创 2025/7/15 23:17:24

本内容是对知名性能评测博主 Anton Putra Redis vs Dragonfly Performance (Latency - Throughput - Saturation) 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

在本视频中，我们将对比 Redis 和 Dragonfly。我们将观察 set 与 get 操作的延迟，重点关注 P99 百分位。这两个操作可能是你在使用任何缓存时最常用的操作。

我们还将查看吞吐量（THR 输出），了解每个数据库每秒能够处理多少请求，并验证 Dragonfly 声称其吞吐量是 Redis 的 25 倍的说法。

此外，我们还将测量两个数据库的 CPU 使用率、内存使用率和网络吞吐量。

第一次测试：基础测试

为了建立基准，我们将在每个缓存上使用 m7a.medium EC2 实例，它配备一个虚拟 CPU 和 4GB 内存。我们将使用 EKS 集群部署客户端来生成负载。

Dragonfly 最大的卖点是它能够使用多个 CPU 核心，使其更容易进行垂直扩展。因此在第二次测试中，我将为 Dragonfly 使用 m7a.xlarge 实例，它拥有 4 个虚拟 CPU 和 16GB 内存。

由于 Redis 大多是单线程的，因此我会采用水平扩展的方式来扩展 Redis。我将使用四个 m7a.medium 实例组成一个由四个 master 节点构成的集群，以匹配 Dragonfly 的 4 个 CPU 和 16GB 内存的容量。

如你从 AWS 控制台看到的，第一次测试中我为两个数据库都使用了中型实例，并为 EKS 集群使用了三个 xlarge 实例，用于部署监控组件（如 Prometheus 和 Grafana），以及部署客户端以生成负载。而在第二次测试中，我将 EKS 扩展到四个节点，为 Dragonfly 使用 xlarge 实例，为 Redis 集群使用 medium 实例。

AWS 成本很高，因此我希望通过提供一对一的技术支持服务来支持我的频道并支付基础设施费用。详情请见视频描述。

Redis 集群设计

由于 Redis 多数情况下只使用单线程，因此扩展 Redis 需要使用集群。一个典型的生产集群由六个节点组成：三个 master 接受所有请求，并将数据复制到其后面的副本节点。客户端使用哈希函数（hash function）来决定将请求发送到哪一个节点。

如果一个 master 故障了，副本节点会被提升为 master，客户端不会察觉任何变化。这就是所谓的高可用（High Availability）。为了使集群正常工作，master 节点的数量应为奇数（例如 3、5、7 等），这样即便一个 master 故障，仍有多数可决定将副本提升为 master。

当然，如果你不需要高可用性（即只是把 Redis 当作缓存使用），一旦数据缺失，应用可以从别的地方（如数据库）重新获取数据，那么也可以不设置副本。此时你可以将 cluster-replicas 属性设置为 0，这样可以将基础设施成本减半。

所以在这次测试中，为了匹配 Dragonfly 的 4 个 CPU，我使用了一个由四个 master 组成、不含副本的 Redis 集群。

Dragonfly 的已知问题

Dragonfly 存在一个已知问题：当使用某些监控系统（如 Prometheus）时，CPU 使用率会异常偏高。这个问题是由于 Dragonfly 使用了相对较新的 io_uring API，即使是网络操作也会被标记为 IO 等待（iowait），从而阻塞 CPU 使用率的准确显示。至少这是 Dragonfly 开发者的解释。

我在之前也对使用相同 API 的框架做过基准测试，但没有观察到这种行为。

虽然有一些解决方案，但从运维角度来看，你需要为这个数据库单独创建一套仪表盘和告警系统，这并不理想。这个问题似乎在新版内核中已被解决，但在此之前仍可以忽略，并不会影响 Dragonfly 的性能表现。