Next Generation Cloud-native In-Memory Stores: From Redis to Valkey and Beyond

本研究通过在 Kubernetes 环境中对 Valkey、KeyDB 和 Garnet 等 Redis 替代方案进行真实负载基准测试，全面评估了它们在吞吐量、延迟、资源效率及迁移复杂度等方面的性能权衡与长期可行性，填补了当前云原生内存数据存储领域实验评估的空白。

要点

这篇论文就像是一份**“内存数据库界的‘换车指南’"**。

想象一下，现代互联网应用（比如淘宝、抖音、游戏服务器）就像是一个个繁忙的超级物流中心。在这个中心里，有一类特殊的“货架”叫内存数据库（比如大家熟知的 Redis）。它们的特点是：东西放在手边，拿取速度极快，但容量有限，而且维护起来很讲究。

过去十年，Redis 是这个领域的“绝对王者”，就像大家都开的丰田卡罗拉，皮实、好用、配件多。但是，最近 Redis 的“车主”（公司）改了**“用车规则”**（许可证变了），这让很多喜欢“开源自由”的社区和大型公司有点担心：以后这车还能随便改吗？还能免费用吗？

于是，市场上出现了三款新的“车型”想要取代或补充 Redis：Valkey、KeyDB 和 Garnet。

这篇论文就是由瑞典和迪拜的几位学者组成的“试驾评测团”，在真实的“云环境”（就像在复杂的城市交通中）里，对这四款车进行了一场硬核路测。

---

🚗 三位“挑战者”是谁？

1. Valkey（Linux 基金会出品）：

   • 人设： 它是 Redis 的“亲兄弟”，直接 fork（复制）了 Redis 的代码，然后大改。
   • 特点： 它保留了 Redis 所有的“操作习惯”（API 兼容 100%）。你以前怎么开 Redis，现在怎么开它，完全不用学新技能。但它给引擎加了涡轮增压（多线程技术），跑得更快。
   • 背景： 由 Linux 基金会牵头，AWS、谷歌等大厂都支持，就像是一个“大家伙”组成的工会，非常稳。

2. KeyDB（老牌选手）：

   • 人设： 它也是 Redis 的“亲戚”，早在 2019 年就出来了。
   • 特点： 它主打“多核并行”，试图利用电脑的所有 CPU 核心来加速。
   • 隐患： 最近它有点“躺平”，更新很少，就像一辆虽然还能跑，但可能快没人修的老车。

3. Garnet（微软研发）：

   • 人设： 它不是 Redis 的复制品，而是重新造了一辆车。
   • 特点： 它用微软最新的 .NET 技术从头构建，性能极强，就像一辆 F1 赛车，速度快得惊人，而且特别省油（省内存）。
   • 缺点： 因为它是“新车”，操作按钮和原来的 Redis 不太一样（兼容性只有 70%）。如果你要换它，得把车里所有的操作习惯都重新学一遍，改装成本很高。

---

🏁 评测结果：谁赢了？

评测团在 Kubernetes（一种管理云服务器的工具）里，模拟了两种极端路况：

• 路况 A（疯狂写数据）： 像双十一抢购，大家都在疯狂下单（写操作）。
• 路况 B（疯狂读数据）： 像看新闻，大家都在疯狂刷新（读操作）。

1. 速度（吞吐量）

• 🏆 冠军：Garnet
  它就像 F1 赛车，在高速公路上（高并发）跑得最快。它的速度比老款 Redis 快了 108%！也就是说，同样的时间里，它能处理两倍多的请求。
• 🥈 亚军：Valkey
  它比 Redis 快了 30%-38%。虽然不是最快的，但已经非常快了，而且很稳。
• 🥉 季军：KeyDB
  只比 Redis 快了 10%-15%，提升不明显。

2. 延迟（反应时间）

• Garnet 依然最稳，反应最快，极少出现“卡顿”。
• Valkey 在读取数据时反应很快，但在疯狂写入时偶尔会有一点点小波动。
• KeyDB 表现最不稳定，有时候会突然“卡一下”（延迟变高），就像开车时偶尔会踩空油门。

3. 油耗（资源效率）

• Garnet 最省油！它用更少的 CPU 和内存就能跑同样的速度，帮公司省下了大量的“电费”和“服务器租金”。
• Valkey 也比较省油，比 Redis 省 20% 左右。
• KeyDB 反而更费油！它为了那一点点速度提升，多消耗了 10%-15% 的 CPU，性价比不高。

---

💡 给老板们的“购车建议”

论文最后给出了非常实用的建议，就像修车师傅给你的忠告：

• 如果你现在正开着 Redis，想换个更稳的：
  👉 选 Valkey。
  理由：它和 Redis 长得一模一样，你不需要重新装修你的“车库”（代码），直接换引擎就行。而且它有大厂背书，未来不用担心没人修。这是最稳妥、最划算的选择。

• 如果你要建一个全新的、追求极致速度的系统：
  👉 选 Garnet。
  理由：虽然换车麻烦（需要重写代码），但它的性能是碾压级的，长期来看能帮你省下巨额的服务器成本。适合那些“不差钱但求快”的新项目。

• 关于 KeyDB：
  👉 暂时别碰。
  理由：它提升不大，还费油，而且最近没人管它了。就像一辆没人修的老车，风险太大。

📝 一句话总结

这篇论文告诉我们：Redis 的“继任者”里，Valkey 是“最完美的平替”，Garnet 是“性能怪兽”，而 KeyDB 可能只是个“过渡品”。 对于大多数公司来说，Valkey 是当下最明智的选择。

技术摘要

论文技术总结：下一代云原生内存存储：从 Redis 到 Valkey 及未来

1. 研究背景与问题 (Problem)

随着大数据时代的到来，内存键值数据存储（In-memory Key-Value Datastores）已成为现代云原生基础设施中实时分析和低延迟服务的关键组件。长期以来，Redis 凭借其简单性、高性能和庞大的生态系统，成为了事实上的行业标准。

然而，Redis 近期面临的许可证变更（从 BSD 改为 RSALv2/SSPLv1）引发了社区和组织的担忧，特别是那些优先考虑开源原则的机构。这促使了多种替代方案的兴起，主要包括：

• Valkey：由 Linux 基金会发起的 Redis 社区分支，旨在保持 API 完全兼容的同时提升性能。
• KeyDB：一个多线程的 Redis 分支，旨在利用多核架构提高吞吐量。
• Garnet：由微软研究院从头构建的高性能实现，基于现代 .NET 运行时优化。

现有研究的不足：目前的文献缺乏对这些新兴替代方案在真实工作负载和云原生环境（如 Kubernetes）下的系统性实验评估。大多数现有比较依赖于厂商宣传或狭窄的用例，缺乏对迁移复杂度、操作兼容性和长期可持续性的综合评估。

2. 方法论 (Methodology)

本研究在 Kubernetes 环境中部署了 Redis、Valkey、KeyDB 和 Garnet，进行了严格的基准测试。

2.1 实验环境

• 基础设施：基于 Kubernetes (v1.31.5) 的云原生部署，使用 Ubuntu 24.04 LTS。
• 资源配置：每个实例限制为 2 核 CPU 和 8 GiB 内存（模拟生产环境约束），禁用持久化以专注于内存性能。
• 版本：Redis v7.2.7, Valkey v8.0.2, KeyDB v6.3.4, Garnet v1.0.62。

2.2 工作负载设计

使用行业标准工具 memtier_benchmark，并针对真实场景进行了以下配置：

• 数据分布：采用 Zipfian 分布模拟“热键”访问模式。
  • **写密集型 **(Workload A)：50% SET / 50% GET，偏斜参数 $\alpha=0.9$。
  • **读密集型 **(Workload B)：5% SET / 95% GET，偏斜参数 $\alpha=1.4$。
• 内存压力：预加载数据使内存利用率达到约 75%，避免测试空内存状态。
• 并发测试：并发连接数从 50 到 500 递增，每个测试运行 300 秒（含 60 秒预热）。

2.3 评估指标

• 吞吐量 (Throughput)：每秒操作数 (ops/sec)。
• 延迟 (Latency)：重点关注 P99 和 P999 尾部延迟。
• 资源效率：CPU 利用率、内存效率及归一化后的资源效率指数。
• 统计显著性：使用 t 检验确保性能差异具有统计学意义。

3. 系统架构对比 (Architecture Overview)

特性	Redis	Valkey	KeyDB	Garnet
线程模型	单线程	单线程 (I/O 多线程增强)	多线程	多线程 (无锁结构)
Redis API 兼容性	100%	100%	95%	70%
许可证	RSALv2/SSPLv1	BSD-3	BSD-3	MIT
开发活跃度	高	高	低	中
核心优势	生态成熟	社区驱动，性能提升	多线程利用	现代硬件优化，.NET 运行时

4. 关键结果 (Key Results)

4.1 吞吐量 (Throughput)

• Garnet：表现最佳。在 500 并发连接下，写密集型工作负载吞吐量比 Redis 高 108%，读密集型高 110%。
• Valkey：表现稳健。写负载提升 32%，读负载提升 38%。其优化的 I/O 多线程在读取操作中表现尤为突出。
• KeyDB：提升有限。写负载提升约 12%，读负载提升 15%，且在高并发下提升幅度不如预期。

4.2 延迟 (Latency)

• P99 延迟：Garnet 最低，比 Redis 低 40-55%。Valkey 在读取负载下表现优异，延迟降低 25%。KeyDB 的延迟方差较大，P99 比 Redis 高 15-25%。
• P999 尾部延迟：Garnet 控制最好，稳定性高。Valkey 在写负载高并发下略有退化。KeyDB 表现出最高的尾部延迟方差，暗示存在线程争用问题。

4.3 资源效率 (Resource Efficiency)

• CPU 效率：Garnet 最高，达到同等吞吐量所需的 CPU 比 Redis 少 30-40%。Valkey 效率提升约 15-20%。KeyDB 由于线程调度问题，CPU 利用率反而比 Redis 高 10-15%。
• 内存效率：Garnet 内存占用比 Redis 少 25-30%（得益于 .NET 优化）。Valkey 通过改进的键值存储结构减少了 8-10% 的内存。KeyDB 内存使用与 Redis 相当。

4.4 迁移与兼容性

• Valkey：100% API 兼容，可实现“即插即用”的无缝迁移，且由 Linux 基金会背书，长期可持续性最强。
• Garnet：仅 70% API 兼容，迁移复杂度高，需要重构代码，但性能优势巨大。
• KeyDB：95% 兼容，但开发活动停滞，长期维护风险高。

5. 主要贡献 (Key Contributions)

1. 填补研究空白：提供了首个在 Kubernetes 云原生环境下，针对 Redis 主要替代方案（Valkey, KeyDB, Garnet）的独立、全面基准测试。
2. 多维度评估：不仅关注吞吐量，还深入评估了尾部延迟、资源效率（CPU/内存）、迁移复杂度和长期可持续性。
3. 实证数据支持：通过统计显著性测试，量化了各系统在真实 Zipfian 工作负载下的性能差异，推翻了部分仅基于厂商宣传的假设。
4. 实践指导：针对不同场景（存量系统迁移 vs. 新系统构建）提供了具体的选型建议。

6. 结论与意义 (Significance & Recommendations)

结论

• Valkey 是现有系统迁移的最佳选择。它在保持 100% API 兼容性的同时，提供了显著的吞吐量和效率提升（30-38%），且拥有强大的社区支持，风险最低。
• Garnet 是高性能新部署的首选。其吞吐量是 Redis 的两倍，资源效率极高，能大幅降低云成本，但需承担较高的迁移重构成本。
• KeyDB 不推荐用于生产环境。尽管有多线程架构，但其性能提升有限，资源效率甚至不如 Redis，且开发活动停滞，存在严重的可持续性风险。

意义

本研究为云原生架构师和运维团队提供了关键决策依据。在 Redis 许可证变更的背景下，组织不再需要盲目依赖单一供应商。

• 对于追求稳定迁移的企业，Valkey 提供了平滑过渡路径。
• 对于追求极致性能且具备重构能力的团队，Garnet 展示了下一代内存存储的潜力。
• 研究强调了在云原生环境中，资源效率（CPU/内存成本）与性能同样重要，Garnet 的高效率可能抵消其迁移成本。

未来的工作将集中在集群模式下的水平扩展评估、持久化机制对比以及更复杂的数据结构测试。