今年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 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 项目的详尽性能比较信息，欢迎大家自行对比参考。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
二、速度问题
Dragonfly 基准测试其实是将独立单进程 Redis 实例（只能使用单一核心）与多线程 Dragonfly 实例（可以使用虚拟机 / 服务器上的全部可用核心）进行比较。很明显，这样的粗暴比较并不能代表 Redis 在现实场景下的运行状态。作为技术构建者，我们希望更确切地把握自有技术同其他方案间的差异，所以这里我们做了一点公平性调整：将具有 40 个分片的 Redis 7.0 集群（可使用其中的大部分实例核心）与 Dragonfly 团队在基准测试中使用的最大实例类型（AWS c4gn.16xlarge）进行性能比较。
在这轮测试中，我们看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而这还仅仅只用到全部 64 个 vCore 中的 40 个。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
三、架构差异
1、背景信息
在我们看来，每一位多线程项目的开发者在立项之前，都会根据以往工作中经历过的痛点来指导架构决策。我们也承认，在多核设备上运行单一 Redis 进程（这类设备往往提供几十个核心和数百 GB 内存）确实存在资源无法充分利用的问题。但 Redis 在设计之初也确实没有考虑到这一点，而且众多 Redis 服务商已经拿出了相应的解决方案，借此在市场上占得一席之地。
Redis 通过运行多个进程（使用 Redis 集群）实现横向扩展，包括在单一云实例背景下也是如此。在 Redis 公司，我们进一步拓展这个概念并建立起 Redis Enterprise。Redis Enterprise 提供管理层，允许用户大规模运行 Redis，并默认启用高可用性、即时故障转移、数据持久与备份等功能。
下面，我们打算分享幕后使用的一些原则，向大家介绍我们如何为 Redis 的生产应用设计良好的工程实践。
2、架构设计原则
1）在每个虚拟机上运行多个 Redis 实例
通过在每个虚拟机上运行多个 Redis 实例，我们可以：
- 使用一套完全无共享的架构实现纵向与横向线性扩展。与纯纵向扩展的多线程架构相比，这套方案能始终提供更好的架构灵活性。
- 提高复制速度，因为复制操作是跨多个进程并发完成的。
- 从虚拟机故障中快速恢复。因为新虚拟机的 Redis 实例将同时填充来自多个外部 Redis 实例的数据。
2）将每个 Redis 进程限制为合理的大小
我们不允许单一 Redis 进程的大小超过 25 GB（运行 Redis on Flash 时上限为 50 GB）。如此一来，我们就能：
- 在出于复制、快照保存、Append Only File（AOF）重写等目的进行 Redis 分叉时，既享受边写边复制的好处，又无需承担繁重的内存开销。若非如此，我们（或客户）将需要支付昂贵的资源成本。
- 为了轻松管理整个集群，我们希望每个 Redis 实例都保持在较小体量，借此加快迁移分片、重新分片、扩展和重新均衡等的执行速度。
3）横向扩展才是最重要的
以横向扩展的方式灵活运行内存数据存储，是 Redis 获得成功的关键。下面来看具体原因：
- 更佳弹性
我们在集群中使用的节点越多，整个集群的健壮性就越强。例如，如果您在三节点集群上运行数据集，且其中一个节点发生降级，则代表有三分之一的集群无法运行；但如果是在九节点集群上运行数据集，同样是其中一个节点发生降级，则只有九分之一的集群无法运行。
- 易于扩展
在横向扩展系统当中，向集群添加一个额外节点、并将数据集的一部分迁移到其中要容易得多。与之对应，在纵向扩展系统中，我们只能直接引入一个更大的节点并复制整个数据集……这是个漫长的过程，而且期间随时有可能闹出麻烦。
- 逐步扩展更具成本效益
纵向扩展，尤其是云环境下的纵向扩展，往往对应高昂的成本。在多数情况下，即使只需要向数据集内添加几 GB 内容，也需要将实例大小翻倍。
- 高吞吐
在 Redis，我们看到很多客户会在小型数据集上运行高吞吐量工作负载，即具有极高的网络带宽及 / 或每秒数据包（PPS）需求。我们以每秒操作数 100 万 + 的 1 GB 大小数据集为例，相较于使用单节点 c6gn.16xlarge 集群（128 GB 内存、64 个 CPU 加 100 Gbps 传输带宽，每小时使用成本 2.7684 美元），三个 c6gb.xlarge 节点（8 GB 内存、4 个 CPU 外加最高 25 Gbps 传输带宽，每小时 0.1786 美元）构成的集群能够将运行成本拉低 20%，而且健壮性反而更高。既然成本效益出色、弹性更强且吞吐量反超，那横向扩展无疑就是比纵向扩展更好的选择。
- 贴近 NUMA 架构
纵向扩展还要求使用能容纳更多核心和大容量 DRAM 的双插槽服务器；相比之下，Redis 这样的多处理架构其实更适应 NUMA 架构，因为其行为特征就接近一种由多个较小节点组成的网络。但必须承认，NUMA 跟多线程架构之间也有天然冲突。根据我们在其他多线程项目中的经验，NUMA 可能令内存数据存储的性能降低达 80%。
- 存储吞吐量限制
AWS EBS 等外部磁盘的扩展速度，显然不及内存和 CPU。事实上，云服务商会根据所使用设备的类型添加存储吞吐量限制。因此，避免吞吐量限制、满足数据高持久性要求的唯一办法，就是使用横向扩展——即添加更多节点和更多的配套网络附加磁盘。
- 临时磁盘
临时磁盘是一种将 Redis 运行在 SSD 上的绝佳方式（其中 SSD 用于替代 DRAM，而非充当持久存储介质），能够在保持 Redis 极高速度的同时将数据库成本保持在磁盘级水平。但临时磁盘也有其上限，一旦逼近这一上限，我们还需要进一步扩展容量——这时候，更好的办法仍然是添加更多节点、引入更多临时磁盘。所以，横向扩展继续胜出。
- 商品硬件
最后，我们的很多客户会在本地数据中心、私有云甚至是小型边缘数据中心内运行 Redis。在这类环境中，绝大多数设备内存不超过 64 GB、CPU 不超过 8 个，所以唯一可行的扩展方式就只有横向扩展。
