最近一个新项目 Dragonfly 声称是最快的 Redis 兼容内存数据存储。

Dragonfly 基准测试将独立的单进程 Redis 实例（只能利用单个内核）与多线程 Dragonfly 实例（可以利用 VM/服务器上的所有可用内核）进行比较。（btw：实际上这就是现实世界中实际运行方式）
Redis认为：这种比较并不能代表 Redis 在现实世界中的运行方式。

Redis做了一项公平的比较，并将 40 个节点机器的Redis 7.0集群（可以利用大部分实例核心）与单台机器上Dragonfly比较（btw：注意是40台服务器 vs. 1台服务器多线程）：
使用 Dragonfly 团队在其基准测试中使用的最大实例类型AWS c6gn.16xlarge进行的一组性能测试. 
在Redis试验中，我们看到 Redis 的吞吐量比 Dragonfly 高 18% - 40%，即使仅使用 64 个 vCore 中的 40 个也是如此。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eCDczau4-1660115839191)(https://redis.com/wp-content/uploads/2022/06/does-redis-need-a-new-architecture-redis-7-cluster-v-dragonfly-1024x617.png?&auto=webp&quality=85,75&width=800)]

架构原则
每个 VM 运行多个 Redis 实例
每个 VM 运行多个 Redis 实例可以让我们：

1. 使用完全无共享的架构，在垂直和水平方向上线性扩展。与仅垂直扩展的多线程架构相比，这将始终提供更大的灵活性。
2. 提高复制速度，因为复制是跨多个进程并行完成的。
3. 从 VM 故障中快速恢复，因为新 VM 的 Redis 实例将同时填充来自多个外部 Redis 实例的数据。

将每个 Redis 进程限制在合理的大小
我们不允许单个 Redis 进程的大小超过 25 GB（在 Flash 上运行 Redis时为 50 GB ）。这使我们能够：

• 在 fork Redis 进行复制、快照和仅附加文件 (AOF) 重写时，享受写时复制的好处，而无需支付大内存开销的代价。如果您不这样做，“是”，您（或您的用户）将付出高昂的代价，如此处所示。
• 为了轻松管理我们的集群，以快速的方式迁移分片、重新分片、扩展和重新平衡，因为 Redis 的每个实例都保持很小。

横向扩展是最重要的
通过水平扩展运行内存数据存储的灵活性非常重要。以下是几个原因：

• 更好的弹性——您在集群中使用的节点越多，您的集群就越健壮。例如，如果您在一个 3 节点集群上运行数据集，并且一个节点降级，则有 1/3 的集群没有运行；但是，如果您在 9 节点集群上运行数据集并且一个节点降级，那么只有 1/9 的集群没有执行。
• 更容易扩展——向集群添加一个额外的节点并将数据集的一部分迁移到它要容易得多，而不是垂直扩展，你需要带来一个更大的节点并复制整个数据集（并考虑所有在这个可能漫长的过程中可能发生的坏事……）
• 逐步扩展更具成本效益——垂直扩展，尤其是在云中，成本高昂。在许多情况下，即使您只需要向数据集添加几 GB，您也需要将实例大小加倍。
• 高吞吐量——在 Redis，我们看到许多客户在小型数据集上运行高吞吐量工作负载，具有非常高的网络带宽和/或高每秒数据包 (PPS) 需求。考虑一个具有 1M+ 操作/秒用例的 1GB 数据集。在单节点 c6gn.16xlarge 集群（128GB，64 个 CPU 和 100gbps，2.7684 美元/小时）而不是 3 节点 c6gn.xlarge 集群（8GB。4 个 CPU 最高 25Gbps，每个 0.1786 美元/小时）上运行它是否有意义) 成本低于 20%，而且方式更稳健？能够在保持成本效益和提高弹性的同时增加吞吐量似乎是这个问题的简单答案。
• NUMA 的现实——垂直扩展也意味着运行具有多核和大型 DRAM 的双插槽服务器；这种基于NUMA的架构非常适合像 Redis 这样的多处理架构，因为它的行为更像是一个由较小节点组成的网络。但 NUMA 对于多线程架构更具挑战性，根据我们在其他多线程项目中的经验，NUMA 可以将内存数据存储的性能降低多达 80%。
• 存储吞吐量限制——AWS EBS 等外部磁盘的扩展速度不如内存和 CPU。事实上，云服务提供商会根据所使用的机器类别施加存储吞吐量限制。因此，有效扩展集群以避免已经描述的问题并满足高数据持久性要求的唯一方法是使用水平扩展，即添加更多节点和更多网络附加磁盘。
• 临时磁盘——临时磁盘是在 SSD 上运行 Redis 的绝佳方式（SSD 用作 DRAM 替代品，但不作为持久存储）并在保持 Redis 速度的同时享受基于磁盘的数据库的成本（看看我们如何在 Flash 上使用Redis执行此操作）。同样，当临时磁盘达到其限制时，最好的方法，并且在许多情况下，扩展集群的唯一方法是添加更多节点和更多临时磁盘。
• 商品硬件——最后，我们有许多在本地数据中心、私有云甚至小型边缘数据中心运行的本地客户；在这些环境中，很难找到内存超过 64 GB 和 8 个 CPU 的机器，而且唯一的扩展方式是横向扩展。

Reddit网友评：
1、Redis认为：你只需要付出额外的努力和开销来运行更多的 redis 进程副本，将它们联网，这完全没问题！看，完全可比且可行。
但是用户认为：运行一个从头开始设计以更好地利用资源并围绕现代 CPU 假设设计的单个应用程序，例如Dragonfly，反而是一种更好的方法

2、Redis运行 40 个复制节点才取得稍微好一点的结果，Dragonfly自称比Redis快，是比较一台机器上单线程redis实例与Dragonfly在所有线程上运行，而Redis这个实验，是用多台服务器去战胜一台服务器上多线程的Dragonfly。
因为Redis是单线程的，为了获得高性能，必须建立 40 多个节点集群，带来额外管理维护成本。