微软开抢年收入上亿美元的 Redis 饭碗?开源性能遥遥领先的 Garnet:无需修改,Redis 客户端可直接接入

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
大数据开发治理平台 DataWorks,不限时长
简介: 微软开源了高性能缓存系统Garnet,旨在挑战 Redis 和 Dragonfly。Garnet 基于 .NET8,提供高吞吐量、低延迟和跨平台支持。它支持 RESP 协议,允许大部分 Redis 客户端无缝迁移。Garnet 的特性包括多连接批量处理以提升扩展性和吞吐量,以及更好的延迟稳定性。适合于需要高性能缓存层来降低成本和提高应用性能的场景。Garnet 的集群模式允许动态键迁移和分片管理,且支持 TLS 和自定义扩展。其网络层设计减少了线程切换开销,存储层则具备丰富的 API 和事务支持。在基准测试中,Garnet 在吞吐量和延迟上优于 Redis 和 KeyDB,展现出优秀的扩展性。

Redis 和 Dragonfly 该有危机感了!

微软开源全新缓存存储系统 Garnet

近日,微软正式开源缓存存储系统 Garnet。据微软研究院数据库小组高级首席研究员 Badrish Chandramouli 介绍,Garnet 项目是从零开始构建而成,且以性能为核心考量(特别是吞吐量中的线程可扩展性与更高比例的低延迟水平)。

具体来说,Garnet 具有以下几大优势:

  • Garnet 采用流行的 RESP 线路协议作为起点,因此大多数用户可以不作任何修改、就直接通过大多数编程语言编写的 Redis 客户端直接接入 Garnet
  • Garnet 通过多条客户端连接与小批量形式提供更好的可扩展性与吞吐量,帮助大型应用程序和服务节约运行成本。
  • Garnet 在第 99 及第 99.9 百分位上表现出更好的客户端延迟水平,更高比例的稳定性表现对于现实场景而言至关重要。
  • Garnet 基于最新 .NET 技术,具有跨平台、可扩展和现代化等特点。它在设计上易于开发与调整,且不致牺牲常见场景下的性能水平。通过利用 .NET 丰富的库生态来扩展其 API,并提供开放的优化机会。凭借对 .NET 的充分发掘,GarnetLinuxWindows 平台上均表现出顶尖性能。

据了解,微软研究院自 2016 年以来一直在研究现代 key-value 数据库架构。2018 年,微软将一套嵌入式 key-valueFASTER 开源之后,其性能超出原有系统几个数量级,同时专注于简单的单节点进程内 key-value 模型。

2021 年开始,根据实际用例的需求,微软开始构建一套新的远程缓存存储方案。其中包含一切必要功能,以作为现有缓存存储的可行替代选项。当时微软面临的挑战包括保持 / 增强其在早期工作中已经取得的性能优势,同时考虑如何更好地适应更加现实的普遍网络环境。这项工作的成果就是 Garnet

在被问及 Garnet 适合部署在哪些场景下时,Chandramouli 表示 任何“使用 Redis、KeyDB 或者 Dragonfly 作为缓存存储方案的现有应用程序都适合Garnet 能提供更高的吞吐量、更低延迟、通过减少需要托管的缓存存储分片来降低成本,还可将数据溢出至本地磁盘或 SSD 以缓存超过内存大小的数据。此外,Garnet 也适合各种希望借极高性能缓存层提高性能、降低后端存储服务器或数据库成本的新型应用程序。

Garnet

  • API 功能方面

Garnet 支持广泛的 API,包括原始字符串、分析与对象操作。它还提供分片、复制及动态密钥迁移等功能的集群模式。Gartner 支持客户端 RESP 事务及用 C# 编写的服务器端存储过程,还允许用户在原始字符串及新对象类型之上设置自定义操作。所有这些均可简单使用 C# 编写,因此自定义扩展的开发门槛更低。

  • 网络、存储、集群功能方面

Garnet 使用快速且可插拔的网络层,且支持后续扩展,例如配合内核旁路堆栈。它支持传输层安全(TLS)通信协议和各种基本访问控制。Garnet 的存储层被称为 Tsavorite,是从 OSS FASTER 中分叉而成,可提供一系列强大的数据库功能,例如线程可扩展性、分层存储支持(内存、SSD 和云存储等)、快速非阻塞检查点、恢复、持久操作日志记录、多键事务支持,以及更好的内在管理与重用功能等。

  • Garnet 支持集群模式

除了单节点执行之外,Garnet 还支持集群操作模式,允许用户创建并管理分片和复制部署。Garnet 还支持高效、动态的键迁移方案,借此重新均衡各个分片。用户可以使用标准的 Redis 集群命令来创建并管理 Garnet 集群,各节点则执行 gossip 以共享并演进集群状态。总的来说,Garnet 的集群模式是一项庞大且仍在发展的功能,微软表示,更多细节将在后续文章中与大家分享。

Chandramouli 在回复 The Stack 的邮件中补充道,“我们也期待大家能将 Garnet 在各类其他现实应用中的表现反馈回来。此外,我们还拥有一套基于 C# 的强大存储过程模型,用户可以借此对关注的事务进行自定义。最后,我们将 Garnet 视为面向未来的重要创新工具,包括优化磁盘 I/O、内核旁路网络以及向量数据库等应用场景。”

Garnet 有什么亮点?

云和边缘计算的快速增长让相关应用程序和服务在数据和覆盖范围上均有显著提升。但与此同时,它们也在数据访问、更新与转换层面提出了效率更高、延迟更低、成本更廉的实际要求。这些应用程序与服务往往需要在存储交互方面投入大量运营支出,这也使其成为当今最昂贵、最具挑战性的平台领域之一。以单独可扩展的远程进程形式存在的缓存存储软件层,能够有效降低这些成本并提高应用程序性能。这也推动了缓存存储行业的发展,包括许多大家耳熟能详的开源系统,例如:Redis、Memcached、KeyDB 以及 Dragonfly

与仅支持简单获取 / 设置接口的传统远程缓存存储不同,现代缓存需要提供丰富的 API 与功能集。它们支持原始字符串、Hyperloglog 等分析数据结构,以及排序集和哈希等复杂数据类型。它们还须允许用户为缓存设置检查点和恢复功能、创建数据分片、维护复制副本并支持事务与自定义扩展。

然而,现有系统在保持系统设计简单性的同时,往往难以满足如此丰富的功能需求,包括导致其无法充分利用最新硬件功能(例如多核心、分层存储、快速网络)。此外,其中许多系统在设计之初,也没有考虑到可由应用程序开发者轻松扩展、或者在不同平台 / 操作系统上良好运行等现实需求。

根据介绍,Garnet 在设计上重新考量了整个缓存存储堆栈——从网络处获取数据包、到解析和处理数据库操作、再到执行存储交互

Garnet 的整体架构

下图为 Garnet 的整体架构,可以看到,Garnet 的网络层继承了微软受 ShadowFax 研究启发所建立的共享内存设计。TLS 处理与存储交互在 I/O 完成线程上执行,这就避免了常见的线程切换开销。这种方法能够借 CPU 缓存一致性将数据传输至网络,而非基于需要在服务器上移动数据的传统 shuffle 设计。

Garnet的整体架构


Garnet 项目整体架构

Garnet 的存储设计由两套 Tsavorite 键-值(key-value)存储组成,二者与统一的操作日志进行绑定。前一套存储被称为“主存储”,针对原始字符串操作进行了优化,负责管理内存以避免垃圾收集。第二套则为可选的“对象存储”,主要针对复杂对象及自定义数据类型进行优化,具体涵盖排序集、集、哈希、列表和地理空间等流行数据类型。它们被存储在内存堆上(以保证更新更加高效),并以序列化形式存放在磁盘内。未来,微软还将研究如何通过统一的索引与日志简化 Garnet 的系统维护。

Garnet 设计中的一大显著特点,就是采用了 Tsavorite 存储 API。该 AIP 用于提供更大、更丰富且可扩展的 RESP API 表面,能够执行读取、更新插入、删除以及 原子读取-修改-写入 等操作,且全部通过 Garnet 的异步回调实现以便在每项操作期间的多个点上插入逻辑。存储 API 模型还确保 Garnet 能够将对问题的解析与查询处理,同并发、存储分层和检查点等其他存储功能彻底分开。

此外,Garnet 还进一步增加了对基于双阶段锁定的多键事务的支持。用户可以使用 RESP 客户端事务(MULTI-EXEC)或使用 C# 中的服务器端事务存储过程。

Gartner 的性能表现

微软研究团队通过展示比较了 Gartner 与其他领先开源缓存存储方案间的关键性能指标。

首先,团队预先配置了两套运行 Linux 系统(Ubuntu 20.04)的 Azure 标准 F72s v2 虚拟机(每虚拟机 72vCPU144 GiB 内存),且启用了加速 TCP。其中一套虚拟机运行各种缓存存储服务器,另一套则专门发布工作负载。这里微软使用自己的基准测试工具 Resp.benchmark,统一由它给出性能测试结果。

微软将 Garnet 与最新开源版本的 Redis(v7.2)、KeyDB(v6.3.4) 以及 Dragonfly(v6.2.11) 进行了比较。在实验中,微软使用了均匀随机分布的键(Garnet 的共享内存设计对于非随机分布的键具有更好的性能优化效果)。在这些实验中,数据会被预先加载至每台服务器上,再嵌入内存中。

实验一:不同数量客户端会话的吞吐量比较

从大指 GET 操作(每批 4096 条请求)加低负载(8 字节键与值)起步,尝试最大限度减少网络开销,并逐步增加客户端会话数量以比较系统性能。从下图中可以看到,Garnet 表现出的可扩展性超越了 RedisKeyDB,同时实现了比所有三大基线系统更高的吞吐量(y 轴取对数坐标)。请注意,虽然 Dragonfly 的扩展性能与 Garnet 类似,但前者属于纯内存内系统。此外,当数据库大小(即预加载的键数量)明显超过处理器的缓存大小时(2.56 亿个键),Garnet 相较于其他系统仍拥有强劲的吞吐量表现。

不同数量客户端会话的吞吐量比较


数据库大小为(a)1024 个键及(b)2.56 亿个键时,不同数量客户端会话对应的吞吐量(对数坐标)

实验二:不同批量大小的吞吐量比较

接下来,使用 GET 操作加固定数量(64)的客户端会话来改变批量大小。跟之前的实验一样,继续尝试两种不同的数据库大小。如下图所示,即使不采用分批处理,Garnet 的性能同样表现更好;而在采用分批处理后,即使批量规模很小,Garnet 的性能优势也在增强。负载大小与实验一相同,且 y 轴同样取对数坐标。

不同批量大小的吞吐量比较


数据库大小为(a)1024 个键及(b)2.56 亿个键时,不同批量大小下的吞吐量比较(取对数坐标)

实验三:不同数量实施意见会话的延迟比较

接下来测试的是各种系统的客户端延迟。如下图所示,随着客户端会话数量增加,与其他系统相比,Garnet 在各个百分位上的延迟(以微秒为单位)均更低也更加稳定。实验中,以 GET 操作占 80%SET 操作占 20% 的混合比例发送操作,且不做分批处理。

不同数量实施意见会话的延迟比较


不同客户端会话数量时,(a)中位数、(b)第 99 百分位与(c)第 99.9 百分位处的延迟水平

实验四:不同批量大小的延迟比较

Garnet 的延迟水平针对自适应客户端的批量与查询系统进行了优化。微软将批量大小从 1 增加到 64,并在下图中整理出具有 128 个活动客户端连接时不同百分位上的延迟水平。从下图中可以看到,Gartner 的延迟整体较低。与之前的实验一样,同样采用 GET 操作占 80%SET 操作占 20% 的混合比例。

不同批量大小的延迟比较


不同批量大小下,(a)中位数、(b)第 99 百分位以及(c)第 99.9 百分位上的延迟水平

开发者:Redis 需要进行重大性能优化了!

从基准性能图表来看,GET 命令的吞吐量超过了 Dragonfly 十倍以上。虽然第 50 百分位的延迟水平略高于 Dragonfly,但第 99 百分位上的延迟却比 Dragonfly 更低。GarnetDragonfly 在吞吐量和延迟上的表现均远远优于 Redis,不少开发者认为,这表明 Redis 可能需要进行重大性能优化。

开发者 hipadev23 表示,“Garnet 确实是首个在低并发与高并发水平上均优于 Redis 的替代方案,这是一项很了不起的成就。Redis 可能需要进行重大性能优化。”

开发者 mtmk 认为,对于需要直接在微软 Windows Server 上运行 Redis(或者兼容),但又不想依赖于 WSL2 的朋友们来说,Garnet 的出现肯定是个好消息。以往由 Redis 端口(现处于归档状态)造成的内存使用问题(主要是由于内存映射文件 AFAIK)将不复存在。

也有不少开发者仍旧坚定地选择 RedisRedis 在某些方面对开发者更友好,而且运行时间更长更稳定。对于 Garnet,大家在许可协议、产品定价、更新维护等方面普遍较为担心。throwaway38375 表示,“Redis 在许可协议或者产品定价方面应该会更稳定,而且它毕竟经历了数十亿小时的生产运行考验。Redis 也更容易安装和理解。” Someone 认为,“对于这样一个微软研究院推出的项目,我最担心的不是许可协议和产品定价,而是缺乏更新(功能、维护甚至是安全更新)”。

garnet-releases

Docker 容器运行情况

  • 下载源码构建 Garnet 镜像,Dockerfile 文件编写如下:
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /source

# Copy files
COPY . .
RUN dotnet restore
RUN dotnet build -c Release

# Copy and publish app and libraries
WORKDIR /source/main/GarnetServer
RUN dotnet publish -c Release -o /app --self-contained false -f net8.0

# Final stage/image
FROM mcr.microsoft.com/dotnet/runtime:8.0
WORKDIR /app
COPY --from=build /app .

# Run GarnetServer with an index size of 128MB
ENTRYPOINT ["/app/GarnetServer", "-i", "128m"]
  • Garnet 镜像启动运行

Garnet run

  • Garnet vs Redis 运行资源统计

image.png

注意:目前 Garnet v1.0.0 版本构建 Docker 镜像,初始化所需最低资源规格:1c/2048M。当资源小于这个规格,就会 OOM 异常:

Unable to initialize server due to exception: Exception of type 'System.OutOfMemoryException' was thrown.

By the way:Garnet 是用 C# 开发的

在社区讨论中,不少开发者惊讶于 Garnet 项目居然是用 C# 开发的。

开发者 west0n 表示:“最让我惊讶的是,Garnet 项目居然是用 C# 开发的,而 Dragonfly 是用 C++ 开发的,Redis 则是用 C 开发的。” 开发者 whimsicalism 更是直言“太意外了,垃圾收集语言 C# 编写的 Garnet 居然击败了 RedisDragonfly。”

也有开发者对此给出的评价较为中肯,pjmlp 认为“垃圾收集语言跟垃圾收集语言可不一样,像 C#.NET 这些语言其实提供了跟 C++ 相当的所有性能调优选项。” 他表示,大家该做的是认真学习,而不是把所有垃圾收集语言都归为一类,再一棒子打死。

此外,更具体地讲,MSIL.NET 在设计上也能支持 C++,而 C#F# 等语言也有办法访问这些功能。即使某些功能未在语言语法层面公开,开发者也可以直接使用 C++/CLI 生成的 MSIL

对此,你怎么看呢?欢迎在评论区留下你的观点。

参考链接:

转载声明:

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
7天前
|
JSON NoSQL Java
Redis入门到通关之Java客户端SpringDataRedis(RedisTemplate)
Redis入门到通关之Java客户端SpringDataRedis(RedisTemplate)
160 0
|
7天前
|
编解码 NoSQL 数据可视化
一个现代化轻量级的跨平台Redis桌面客户端
一个现代化轻量级的跨平台Redis桌面客户端
223 0
|
7天前
|
NoSQL Redis C++
VS2017的redis客户端实现
VS2017的redis客户端实现
|
7天前
|
JSON NoSQL Java
【Redis】2、Redis 的 Java 客户端(Jedis 和 SpringDataRedis)
【Redis】2、Redis 的 Java 客户端(Jedis 和 SpringDataRedis)
54 0
|
7天前
|
NoSQL 数据处理 调度
【Redis深度专题】「踩坑技术提升」探索Redis 6.0为何必须启用多线程以提升性能与效率
【Redis深度专题】「踩坑技术提升」探索Redis 6.0为何必须启用多线程以提升性能与效率
295 0
|
7天前
|
JSON NoSQL Java
深入浅出Redis(十三):SpringBoot整合Redis客户端
深入浅出Redis(十三):SpringBoot整合Redis客户端
|
7天前
|
NoSQL 网络协议 Java
Redis客户端Lettuce深度分析介绍(上)
Spring Boot自2.0版本开始默认使用Lettuce作为Redis的客户端(注1)。Lettuce客户端基于Netty的NIO框架实现,对于大多数的Redis操作,只需要维持单一的连接即可高效支持业务端的并发请求 —— 这点与Jedis的连接池模式有很大不同。同时,Lettuce支持的特性更加全面,且其性能表现并不逊于,甚至优于Jedis。本文通过分析Lettuce的特性和内部实现(基于6.0版本),及其与Jedis的对照比较,对这两种客户端,以及Redis服务端进行深度探讨。
44078 3
|
7天前
|
存储 缓存 NoSQL
为什么Redis使用单线程 性能会优于多线程?
在计算机领域,性能一直都是一个关键的话题。无论是应用开发还是系统优化,我们都需要关注如何在有限的资源下,实现最大程度的性能提升。Redis,作为一款高性能的开源内存数据库,因其出色的单线程性能而备受瞩目。那么,为什么Redis使用单线程性能会优于多线程呢?
25 1
|
7天前
|
监控 NoSQL 测试技术
解密Redis性能:如何通过性能测试提升系统稳定性和效率
解密Redis性能:如何通过性能测试提升系统稳定性和效率
|
7天前
|
NoSQL Linux 网络安全
Redis 客户端工具
Redis 客户端工具
28 0