宣布RedisGears1.0：Redis的无服务器引擎

我们很高兴地宣布RedisGears的普遍可用性，一个在Redis中提供无限可编程性的无服务器引擎。ag万博下载万博最新版本下载苹果开发人员可以使用再装备为了提高应用程序的性能和实时处理数据，而架构师可以利用它来驱动架构的简单性。

作为执行的动态框架功能在Redis中实现数据流，RedisGears抽象了数据的分布和部署，以加速使用Redis中的多个模型的数据处理。RedisGears可以让你在Redis中编写你想要的一切，将函数部署到每个环境中，简化你的架构并降低部署成本，并在数据所在的地方运行你的无服务器引擎。

RedisGears可以部署在各种用例中:

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

RedisGears是遗传算法

除了宣布RedisGears，我们还推出了它的第一个配方。“配方”是一组函数和它们可能具有的任何依赖项，它们一起解决更高级别的问题或用例。我们的第一个食谱是rgsync．也被称为写在后面，这个功能可以让你把Redis作为你的前端数据库，而RedisGears保证所有的更改都写入你现有的数据库或数据仓库系统。

为了帮助您理解RedisGears的强大功能，我们将首先解释RedisGears体系结构及其优点。然后我们将讨论这些优点如何应用于write behind，并通过我们创建的演示应用程序演示其行为。

RedisGears架构

RedisGears的核心是一个引擎，它通过可编程接口执行用户提供的流或函数。函数可以由引擎以一种特别的map-reduce方式执行，也可以由不同的事件触发，以进行事件驱动的处理。存储在Redis中的数据可以通过函数进行读写，内置的协调器便于处理集群中的分布式数据。

大体来说，下图描述了RedisGears的组件:

RedisGears有三个主要组件：

1. GearsCoordinator在数据库中的每个分片上协调函数的分布式执行。
2. 齿轮安全计计划和触发函数的执行。可以通过流中的新条目或键空间通知来临时触发函数。在后者中，函数可以是同步执行带着通知。（GearsExecutor在上图中不可见，但由事件/触发器部分暗示。）
3. GearsEngine是RedisGears的运行时执行环境。

在这三个核心组件之上，RedisGears还包括一个快速的底层C-API。现在你可以通过Python集成这个C-API，还有更多的语言正在开发中。

RedisGears最小化了执行时间和数据流之间的分片通过运行你的函数尽可能接近你的数据。通过把你的无服务器引擎放在内存中，你的Redis数据所在的地方，它消除了获取数据所需的耗时的往返，加快了事件和流的处理。

RedisGears允许你“编写一次，部署到任何地方”。你可以为一个独立的Redis数据库编写函数，并将它们部署到生产环境中，而不必为集群数据库调整脚本。

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

write - behind

应对用户/请求数量的突然激增的能力是现代公司和组织必须考虑的事情。例如，“黑色星期五”和“网络星期一”的流量会让平时的流量相形见绌。

如果没有为这样的峰值做好计划，可能会导致性能差、意外停机，并最终导致收入损失。另一方面，将您的解决方案过度扩展到这些峰值也可能是昂贵的。关键是找到一个经济有效的解决方案，可以满足您的需求和要求。

传统的关系/基于磁盘的数据库常常无法处理负载的显著增加。这就是RedisGears发挥作用的地方。RedisGears的write-behind功能依赖于Redis来完成繁重的工作，异步管理更新，减轻负载，减少后端数据库的峰值。RedisGears还保证所有的更改都被写入你现有的数据库或数据仓库系统，保护你的应用程序从数据库故障和提高你的应用程序的性能到Redis的速度。这大大简化了你的应用程序逻辑，因为它现在只需要与一个前端数据库Redis对话。write-behind功能最初是支持Oracle、MySQL、SQL、SQLite、Snowflake和Cassandra。

write - behind实现

下图显示了RedisGears的write-behind功能的架构:

其操作如下:

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

这两个函数共同构成了我们所说的齿轮“配方”。（请注意，write-behind的方法捆绑在rgsync（RedisGears sync）包，以及其他几个数据库同步方法。）

如上所述，只有成功地将事件添加到流中时，才会发生第三步。这意味着，如果在客户端得到写操作的确认后发生了错误，Redis复制、自动故障转移和数据持久性机制将保证更新事件不会丢失。默认情况下，write-behind RedisGears功能提供至少一次交货属性用于写入，这意味着数据将写入一次目标，但在失败时可能会更多。可以设置RedisGears函数来提供完全一样如果需要，可以使用e-delivery语义，确保任何给定的写操作只在数据位于目标数据库上时执行。

通过写延迟提高应用程序性能

为了展示write-behind的好处，我们开发了一个演示应用程序其中我们添加了端点以支持两种方案：

1. 应用服务器直接写入后端数据库。
2. 该应用程序将Redis作为一个前端数据库，而RedisGears对后端数据库进行写后操作。

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

为了在应用程序中模拟峰值，我们创建了一个峰值测试k6，其中我们模拟了一个从1到48个并发用户的短突发。

为了检查整个系统如何处理该峰值，我们跟踪了应用程序上实现的HTTP负载和延迟以及底层数据库系统性能。下图显示了两种情况左侧间隔显示了仅MySQL解决方案的结果，而右侧间隔显示了写后情况的结果用齿轮。

这个图表显示了一些重要的发现:

1. 在应用程序级别，应用程序请求图表显示，我们已从每秒处理多达5K个请求转变为最多可满足4倍以上的请求，使用相同的底层硬件。
2. 数据库图表显示MySQL每秒插入/更新的数量增加。这是因为write-behind将对后端数据库的更新批处理到单个请求中（这是可能的，因为在这个场景中，前端应用程序与后端数据库解耦）.这是一种双赢的情况，因为您的HTTP应用程序不必等待数据库写入操作完成，而且您还可以利用最初为您的客户调整后端数据库大小的资源做更多工作“免费”获取更多信息
3. 正如预期的那样，随着RedisGears的加入，与快速应用程序和慢速后端数据库之间的同步性被删除直接相关的是，我们已经从32毫秒的第95个分位数应用程序延迟值移动到10毫秒以下的延迟。应用程序回复的平均等待时间不是8毫秒，而是2毫秒。您的应用程序不仅运行得更快，更重要的是，它们还将更稳定、更具弹性。

开始使用RedisGears

我们真的很兴奋，并写在后面。我们相信，write-behind用例只是RedisGears可以解决的无限问题的开始。

我们希望这篇博文能鼓励你尝试RedisGears。请查看RediGears.io，其中包含了大量的例子和如何开始的提示。你可以在这里找到更多很酷的演示:

• 先知齿轮，使用Facebook的先知RedisTimeSeries用于时间序列数据预测的批处理过程
• 动物识别演示是一个使用Redis Streams, RedisGears和RedisAI进行实时视频分析的例子。检测网络摄像头流中的猫）。
• Edge实时视频分析是一个结合Redis Streams、RedisAI和RedisTimeSeries的演示，与RedisGears粘合在一起。

RedisInsight的新版本即将发布，其中包含对RedisGears执行函数和查看RedisGears中注册函数的支持。我们将为您提供一个快速的GIF，您可以期待：

快乐编码！