宣布 RedisGears 1.0：无服务器 Redis 引擎

我们很高兴地宣布RedisGears 现已普遍上市，这是 Redis 中提供无限可编程性的无服务器引擎。开发人员可以使用RedisGears改善应用程序性能，实时处理数据，而架构师可以使用它来推动架构简化。

作为用于执行函数的动态框架，这些函数可实现 Redis 中的数据流，RedisGears 抽象了数据的分配和部署，以便使用 Redis 中的多模型加速数据处理。RedisGears 允许您在 Redis 中对所需的一切进行编程，将函数部署到每个环境，简化架构并降低部署成本，在您的数据所在之处运行无服务器引擎。

RedisGears 可用于各种用例

• 实时数据处理，因为它嵌入 Redis 中运行
• 可靠的事件处理，例如串流中的新消息或 Redis 中实体的更新，以及
• 跨多个数据结构的操作和数据模型，在分片之间以透明的方式进行。

RedisGears 已成为 GA

除了宣布 RedisGears 外，我们还发布了它的第一个秘方。一个“秘方”是一组函数（和它们可能具有的任何依赖项），这些函数共同解决高级问题或用例。我们的第一个秘方是rgsync。此功能还称为写后，它可以让您将 Redis 作为前端数据库，而 RedisGears 会保证将所有更改写入现有数据库或数据仓库系统。 

为了帮助您了解 RedisGears 的强大之处，我们将从解释 RedisGears 架构及其优势开始。然后，我们将讨论这些优势如何应用于写后，并通过我们创建的演示应用程序展示其行为。

RedisGears 架构

RedisGears 的核心是一个通过可编程接口执行用户提供的流或函数的引擎。引擎可以通过临时 MapReduce 方式执行函数，或由不同事件触发以进行事件驱动的处理。函数可以读取和写入存储在 Redis 中的数据，内置协调器有助于在一个集群中处理分布式数据。

总体而言，此图表描绘了 RedisGears 的组件

RedisGears 有三个主要组件

1. 齿轮协调器协调在数据库的各个分片执行功能的分布式执行。
2. 齿轮执行器安排并触发执行功能。功能可以通过广告形式来触发，也可以通过流中的新条目或键空间通知来触发。在后者中，该功能可以与通知同步执行。（齿轮执行器在上图中不可见，但事件/触发器部分暗示了它。）
3. 齿轮引擎是 RedisGears 的运行时执行环境。

在这三个核心组件的基础上，RedisGears 还包含一个快速底层 C-API 以便于编程。如今，您可以通过 Python 集成此 C-API，其他语言也已在筹备中。

通过尽可能贴近您的数据来运行您的函数，RedisGears 将执行时间和分片之间的数据流降至最低。通过将您的无服务器引擎置于内存中（这里是您的 Redis 数据驻留的位置），它消除了获取数据所需的时间消耗型行程，加快了事件和流的处理。

RedisGears 允许您“一劳永逸地编写，随时随地部署”。您可以为独立的 Redis 数据库编写您的函数，并将其部署到生产环境，而无需调整脚本以适应群集数据库。

将实时数据与无服务器引擎相结合，您可以处理跨数据结构和数据模型的数据，而无需多个客户端和数据库连接器的开销。这简化了您的架构并降低了部署成本。

后台写入

应对用户/请求数量突然激增的能力是现代公司和组织必须考虑的事情。例如，黑色星期五和网络星期一的流量可能会倍增于普通日期的流量。

未能规划此类峰值可能会导致性能不佳、意外停机，最终造成收入损失。另一方面，针对这些峰值过度扩展您的解决方案也可能很昂贵。关键是要找到一种经济高效的解决方案来满足您的需求和要求。

传统的关系型/基于磁盘的数据库通常无法应对负载的显着增加。这就是 RedisGears 发挥作用的地方。RedisGears 的后台写入功能依靠 Redis 来处理繁重任务，异步管理更新，减轻后端数据库的负载并减少峰值。RedisGears 还确保所有更改都写入您的现有数据库或数据仓库系统，从而保护您的应用程序免受数据库故障的影响，并将您的应用程序的性能提升到 Redis 的速度。由于现在只须与单个前端数据库（Redis）通信，所以这样大幅简化了您的应用程序逻辑。后台写入功能最初支持 Oracle、MySQL、SQL、SQLite、Snowflake 和 Cassandra。

写入后台实现

下图显示了 RedisGears 的写入后台功能的架构： 

其操作如下

1. 将写操作转到 Redis 哈希键。
2. 此写入触发了一个 第一个 RedisGears 函数，在 Redis Stream 中同步记录了变更。
3. 仅当事件成功添加到流中时，才会向客户端返回确认。
4. 一个 第二个 RedisGears 函数在后台异步执行，并批量处理对目标数据库进行的变更。此操作由流中的新消息触发。

这两个函数共同组成了我们所说的 RedisGears 的“配方”。（请注意，写入后台的配方已一同捆绑在 rgsync（RedisGears 同步）包中，其中还包含其他一些数据库同步配方。）

如上所述，步骤三仅在事件成功添加到流中后才会发生。这意味着，如果在客户端获得对写操作确认之后出现问题，则 Redis 复制、自动故障转移和数据持久性机制可确保不会丢失更新事件。默认情况下，写入后台 RedisGears 功能对写入提供 至少一次交付属性，这意味着数据将写入目标一次，但在发生故障时可能会写入多次。如果需要，还可以设置 RedisGears 函数，以提供 正好一次的交付语义，确保对目标数据库执行任何给定的写入操作仅一次。

通过写入后台改进应用程序性能 

为了展示写入后台的好处，我们开发了一个 演示应用程序，我们已向其中添加了终结点以支持两种场景：

1. 应用程序服务器直接写入后端数据库。 
2. 该应用程序将 Redis 视为前端数据库，而 RedisGears 将写入后台到后端数据库。

在此示例中，我们使用 MySQL 作为后端数据库，以便于测试和复现。

为了模拟应用中的峰值，我们使用 k6 创建了一个尖峰测试，其中我们模拟了一个从 1 个到 48 个并发用户变化的短暂集中爆发。 

为了检查整体系统如何处理尖峰，我们追踪了应用上达到的 HTTP 负载和延迟，以及基础数据库系统性能。下图展示了这两种情况 — 左面的区间展示了仅 MySQL 解决方案的结果，而右面区间展示了具有 RedisGears 的后置写场景的结果。

该图表显示了一些重要发现

1. 在应用层面，应用请求图表显示我们已经从每秒服务 5000 个请求转为每秒服务多达 4 倍的请求，而底层硬件保持不变。  
2. 数据库图表显示 MySQL 每秒插入/更新次数有所上升。这是因为后置写批处理将针对后端数据库的更新打包成单个请求（这仅仅是因为在这种情况下，前端应用和后端数据库已解耦）。这是一个双赢的局面，因为您的 HTTP 应用不必等待数据库写操作完成，而且您还可以通过最初为后端数据库划定的资源完成更多事情 — 您可以“免费”从中获得更多。
3. 正如预期的那样，并且直接关系到您的快速应用和缓慢后端数据库之间的同步性移除，以及 RedisGears 的加入，我们已经从 32 毫秒的 95th 百分位应用延迟值转为低于 10 毫秒的延迟。代替平均等待 8 毫秒才能进行应用回复，现在只需要 2 毫秒。您的应用不仅会运行得更快，但更重要的是，它们还会更稳定、更具弹性。 

开始使用 RedisGears

我们对 RedisGears 和后置写感到非常兴奋。我们相信后置写用例仅仅是 RedisGears 能解决的无数问题中的一小部分。  

我们希望这篇博文能够鼓励您尝试 RedisGears。请查看 RedisGears.io，其中包含许多关于如何开始的示例和提示。您可以在此处找到更多精美的演示: 

• Prophet Gears，使用 Facebook prophet和 RedisTimeSeries 进行时间序列数据预测的批处理
• 动物识别示例 是一个使用 Redis Streams、RedisGears 和 RedisAI 进行实时视频分析（即检测网络摄像头流中的猫咪）的示例。
• 边缘实时视频分析是一个结合了 Redis Streams、RedisAI 和 RedisTimeSeries，并通过 RedisGears 粘合在一起的示例。

新版本的 RedisInsight 即将发布，它将包含对 RedisGears 执行函数和查看 RedisGears 中已注册函数的支持。我们在此为您提供一个简短的 GIF，让您了解可以期待的内容

编码愉快！