Garnet – 来自 Microsoft Research 的新远程缓存存储

原文 ↗ Hacker News 讨论 ↗

性能与架构

  • 基准测试显示，Garnet 的 GET 吞吐量远超 Dragonfly 和 Redis，同时尾延迟也相当甚至更好；有人据此推断 Redis 可能需要进行大幅优化。
  • 以 C# 实现，并大量使用 unsafe 和底层内存操作；许多人认为这证明只要精心调优，.NET 也能达到与 C/C++ 相当的性能。
  • 存储层 Tsavorite（从 FASTER 分支而来）提供线程可扩展性、分层存储、非阻塞检查点、日志、事务，以及改进的内存复用。
  • 也有人怀疑，性能提升更多来自数据结构/算法和多线程，而不仅仅是语言选择本身。
  • 仍有疑问在于它在哪些场景下表现较差，以及在比 72 vCPU 基准机器更小、没那么“强劲”的实例上会如何运行。

Redis 兼容性与语义

  • 它被宣传为可与现有 Redis 客户端配合使用，但 API 兼容性并不完整；对 streams 的支持也不明确。
  • Redis 是单线程的，并且每个命令都完全原子；而 Garnet 是多线程的，并明确指出 MSET 只有在作为事务表达时才是原子的。一些人认为这对“即插即用替代品”来说是个严重的注意事项。
  • 对大多数用例来说，Redis 仍被认为“足够好”且经过了极其充分的实战检验；尽管 Garnet 的数据很亮眼，很多人还是更愿意继续使用 Redis。
  • Redis 集群缓解了单线程限制，但也引入了自身的复杂性。

.NET 生态与 GC 讨论

  • 讨论提到，.NET 和 Java 的 JIT、GC 与性能分析工具，有时能超过手写的 C/C++ 代码，尤其是在多态和托管内存策略方面。
  • .NET 的 spans、structs、unsafe 指针以及堆外选项被视为强大的性能调节手段；关于逃逸分析和栈分配细节也存在争论。
  • 对库生态成熟度和工具链也有分歧：有人说 .NET 的库已经完整且质量很高；也有人认为相比 JVM 仍有差距，并指出要获得“最佳”体验仍高度依赖 Visual Studio。

Azure、Windows 与部署

  • 大家对 Garnet 作为 Windows Server 和 Windows 容器上的原生高性能缓存很感兴趣，因为这可以避免 WSL 或已归档的 Redis 移植版本。
  • 有人希望它能内嵌到 Azure App Service 或类似服务中，采用节点本地缓存并复制到附近节点；他们认为网络跳数本身就是延迟的主要来源。
  • 还提到了 K8s + Cilium 的“local redirect”模式，作为在其他缓存系统中获得局部性收益的一种方式。

许可、治理与信任

  • Garnet 采用 MIT 许可，但需要 CLA；有人将其视为法律层面的常规处理，也有人认为这为重新授权留下了空间。
  • 有人担忧 Microsoft 的专利立场，以及 Microsoft Research 项目常常中途停滞；但也有人指出 Garnet 已在内部使用，并可能发展为 Azure 服务。
  • 还有几条评论把 Garnet 的开放许可与 Redis 不断变化的许可策略和生态分支进行对比，不过也有人因 Redis 的历史和简单性而仍然更信任 Redis。