Redis 的联合创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 近期联合发布了一篇名为《13 年后--Redis 是否需要新的架构？》的文章，旨在分享一些有关 Redis 架构的观点和思考，以佐证“为什么 Redis 的架构仍然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。
文中指出，Redis 是一项基础技术，因此难免偶尔会看到有人在考虑推出一些替代架构。譬如几年前的 KeyDB，以及最新冒头的 Dragonfly —— 声称是最快的 Redis 兼容内存数据存储。“我们相信这些项目带来了许多值得讨论和辩论的有趣技术和想法。在 Redis，我们喜欢这种挑战，因为它要求我们重申 Redis 最初设计的架构原则（向 Salvatore Sanfilippo aka antirez 致敬）。”
博客主要分享了一些有关速度和架构差异的看法，并文章的末尾提供了与 Dragonfly 项目的基准和性能比较的细节。具体如下：
速度
首先他们认为，此前 Dragonfly 基准测试中比较独立的单进程 Redis 实例（只能利用单个 core）和多线程 Dragonfly 实例（可以使用VM/server 上的所有可用 core）的方式并不准确，不能代表 Redis 在现实世界中的运行方式。
因此他们做了自认更加公平的比较，将 40-shard Redis 7.0 Cluster（可以利用大部分实例 core）与 Dragonfly 进行了比较，对 Dragonfly 团队在其基准测试中使用的最大实例类型 AWS c6gn.16xlarge 进行了一组性能测试。
此试验结果表明，Redis 的吞吐量比 Dragonfly 高 18% - 40%（即使仅利用了 64 个 vCore 中的 40 个）。
![]()
![]()
架构差异
“我们相信这些多线程项目的创建者所做的很多架构决定都是受到他们在之前工作中所经历的痛点的影响。我们同意，在多核机器上运行一个 Redis 进程（有时有数十个 core 和几百 GB 的内存）无法利用明显可用的资源。但这并不是 Redis 的设计初衷；这只是许多 Redis 供应商选择运行其服务的方式。”
Redis 通过运行多进程（使用 Redis 集群）水平扩展，即便是在单个云实例的背景下。根据介绍，该公司进一步发展了这一概念并构建了 Redis Enterprise，它提供了一个管理层，允许用户大规模运行 Redis，并默认启用高可用性、即时故障转移、数据持久性和备份。
所以，Yiftach 他们决定分享一些其幕后使用的原则，以帮助大众了解官方认为在生产环境中运行 Redis 的良好工程实践。包括：
- 每个 VM 运行多个 Redis 实例
- 将每个 Redis 进程限制在合理的大小：不允许单个 Redis 进程的大小超过 25 GB（在 Flash 上运行 Redis 时为 50 GB ）
- 通过水平扩展运行内存数据存储的灵活性非常重要
总的来说，他们表示，欣赏来自社区的新鲜、有趣的想法和技术；并指出其中的一些甚至有可能在未来进入 Redis（比如已经开始研究的 io_uring 、更现代的字典、更有策略地使用线程等）。但在可预见的未来，Redis 提供的无共享、多进程架构的基本原则不会被放弃。因为他们认为，这种设计提供了最佳的性能、扩展性和弹性，同时也支持内存、实时数据平台所需的各种部署架构。
更多详情及 Redis 7.0 vs. Dragonfly 基准测试细节可查看官方博客。
值得一提的是，关于 Redis 方面所指出的 Dragonfly 基准测试中“不能代表 Redis 在现实世界中的运行方式”的说法，Reddit 上有网友反驳称：
它绝对代表了现实世界中普通用户运行 Redis 的方式。"在单台机器上运行集群，以便能够使用超过 1 个 core"是额外的复杂性，人们只有在别无选择的情况下才会这样做，如果竞争者无论有多少个 core 都能"just works"，那么最好能有更容易的设置。
还有人表示，这篇文章属于：
Redis 团队可爱的、非常有礼貌的 "actually, no"的回应。
