redis stream_Redis Stream与Amazon SQS

最新推荐文章于 2024-08-13 17:33:34 发布

dfsgwe1231

最新推荐文章于 2024-08-13 17:33:34 发布

阅读量327

点赞数

文章标签：队列数据库 python java redis

原文链接：https://hackernoon.com/redis-stream-vs-amazon-sqs-g21n3y7p

版权

redis stream

你喜欢拳击吗？今天晚上，我为您带来Redis Streams与AWS SQS之间的一场激战。如果您对哪种技术更好，哪种技术能在实际中应用感兴趣，请进行检查！

比赛背后的故事

最近，我们不得不在系统中添加与外部API的通信。这并不稀奇，我们的应用程序中已经有数十个类似的集成。但是，这一次，我们必须满足更严格的每秒速率限制，同时仍然能够最大限度地利用它们。

为了保持快速，简单，我们决定将所有API调用移至子系统。没有数据库，没有前端，只有两个队列（输入和输出），只有一个目的-在限制内尽可能快地命中API。这带来了下一个挑战-选择哪种排队系统？

竞争对手

我们的应用程序是用Ruby编写的，并托管在AWS云中。自然的候选人是AWS SQS ，因为我们已经在系统的其他部分中使用过它。另一方面，我们已经为Sidekiq设置了Redis ，因此我们决定检查Redis Streams是否更合适。如果现有解决方案之一满足了我们的需求，我们不愿引进全新的技术。

AWS SQS有两种形式：FIFO和Standard，它们有区别，因此我们决定分别进行比较。我们最终得到了三个候选人：

AWS SQS（标准）
AWS SQS（先进先出）
Redis Streams（Redis版本5.0）

详细比较

队列系统之间的战斗将包括五个回合。我们将检查：

使用方便
错误处理
坚持不懈
通量
交货

希望您对AWS服务的工作方式有深入的了解，并且了解Redis的工作方式。

我不会再让你等待了。让战斗开始！

战场：队列如何工作？

处理队列消息的典型方法如下所示；系统将消息标记为“待处理”或“运行中”，然后将其发送给使用者。使用者完成处理后，它将通过发送“确认”消息来通知队列成功。然后，邮件的状态从“待处理”更改为“已处理”。

在给定时间内缺少“确认”意味着处理失败，并且该消息不再被视为“待处理”。这样，任何消息都不会永远停留在“挂起”状态。

当处理几次失败时，队列将假定消息本身存在问题，并停止将其发送给客户端。（可选）它也可以将其移动到DLQ（就像消息的墓地一样）。

第一轮：易用性

AWS SQS提供了几种不同的使用方式。从Web界面开始，直到CLI结束，客户端库以多种语言提供。

例如，在Ruby代码中处理消息如下所示：

poll_config = {max_number_of_messages: 10 }
stats = sqs_poller.poll(poll_config) { |messages| process_messages(messages) }

您可以设置批处理大小以及其他描述轮询循环详细信息的参数。当处理块完成时，库负责确认消息。处理完成后，轮询器将返回一个包含一些基本统计信息的对象。（例如，收到的消息数）

使用Redis Streams更复杂。首先，您需要使用CLI或客户端库执行所有操作。不包括Web UI。而且，到目前为止，API提供的命令集受到一定限制。用于处理消息的简单代码如下所示：

redis.xreadgroup('mygroup' , 'Alice' , 'mystream' , '>' , count: 1)
# Process the message
redis.xack( 'mystream' , 'mygroup' , '1526569495631-0' )

看起来很容易，但是有一个陷阱。如果要处理故障，则需要自己编写代码：

redis.xpending('mystream' , 'mygroup' )
# Check the how long message is "pending" and "delivery counter" in the response
redis.xclaim( 'mystream' , 'mygroup' , 'Alice' , 3600000, '1526569498055-0' )

除非您以前使用过redis流，否则您可能不知道这里发生了什么，这清楚地表明使用SQS更容易。如果您想知道这些命令的作用，最好的方法是检查文档。这是我们在使用Redis API时始终会做的事情。

具有Web UI访问权限和更友好的API的AWS在本轮比赛中获胜。

Aws 1：0 Redis

第2轮：错误处理

有两个功能可帮助处理消息处理错误：

重试未确认的消息
将邮件移动到死信队列（DLQ）。

现在，让我们检查一下候选人如何支持他们。

在SQS（FIFO和标准）中，整个流程与队列生命周期集成在一起。您可以使用Web UI或CLI轻松进行设置。有一个选项可以定义“运行中”状态超时，重试限制以及要使用的DLQ队列。

在Redis中，没有Web UI，也没有用于操纵“待定”状态超时或DLQ设置的旋钮。可以从Redis API获取所有需要的数据，但是没有内置的东西可以利用。您必须自己编写错误处理代码。

总而言之，AWS允许您单击几下即可配置错误处理，而Redis则需要您实施自定义解决方案。 AWS在本轮比赛中获胜。

Aws 2：0 Redis

第三回合：坚持

这里的“持久性”是指队列如何存储消息。我将比较队列将消息保留（保留）多长时间以及对已存储消息数的限制。

在AWS SQS中，我们可以将保留时间配置为1分钟到14天之间的任何值。 SQS可以存储无限数量的消息，并且仅对运行中的消息数施加限制。 FIFO设置为20,000，标准队列设置为120,000。

Redis队列的工作方式不同-将所有消息存储在内存中。结果，Redis的内存大小限制了消息的数量（最大数量取决于消息的大小）。您必须手动清除旧邮件中的队列，以确保不会收到内存不足的错误。

将消息存储在内存中还有另一个缺点。如果服务器停机或重新启动，您将丢失所有数据。您可以通过定期创建Redis数据库快照以及记录所有操作日志来缓解这种情况。但这需要其他手动配置。请参阅（ RDB和AOF持久性）。

考虑到开箱即用的AWS持久性配置具有更好的多功能性，AWS再次获胜。

Aws 3：0 Redis

第四轮：吞吐量🏎

队列系统不能成为应用程序的瓶颈。在这一轮中，我将比较不同的队列系统可以传递消息的速度。

在批处理从队列下载的消息时，AWS SQS引入了限制。在每个请求中，您最多可以下载10条消息。如果您的系统需要处理大量消息，则意味着对API的许多查询。最重要的是，如果您使用FIFO队列，您将获得300 /秒的请求上限（可以通过与支持人员联系来增加此限制）。将其与消息批处理结合在一起（单个请求中最多10个消息），对于FIFO SQS，理论上每秒最多接收3000条消息。我的实验表明，实际上，使用单个Ruby线程从FIFO SQS下载250条消息大约需要0.6s。

在这里，您可以像Redis一样看到将消息存储在内存中的好处。对请求的数量没有限制，我在Ruby中下载250条消息的实验耗时约0.001秒。

最重要的是，Redis消息的大小仅受服务器内存大小的限制，而AWS SQS则将消息大小限制为256K。您可以使用扩展客户端库在S3上存储消息有效负载，这会将此限制扩展到2GB，但仍小于Redis。

Redis比AWS SQS快几个数量级。因此，它赢得了本轮比赛。

Aws 3：1 Redis

第五回合：交付📨

在最后一轮中，我将检查队列是否保证先进先出（FIFO）和一次发送。

Redis流始终提供FIFO和一次精确处理。期。

AWS SQS提供两种不同类型的队列。当不需要FIFO和一次处理时，标准的SQS队列是正确的选择。它可以按任何顺序传递消息（即，可以在较早的消息之前传递较新的消息）。它还承诺仅“至少一次”传递（一条消息可以多次传递）。

对于必须具备FIFO的情况，AWS提供FIFO SQS队列。它们以上述限制为代价，保证了FIFO和“恰好一次”交付。

因此，本轮比赛是平局（Redis的优势不大）

Aws 4：2 Redis