SQS与RabbitMQ

Question

我需要创建一个队列进行处理.队列本身的体积相对较小.每小时可能有大约1,000次写入.每个任务的执行可能大约需要一分钟,并且几乎在项目添加到队列后立即处理.

我有没有理由想要实现RabbitMQ,而不是像Amazon SQS那样现成的东西？应用程序需要自己的排队系统而不是SQS之类的原因是什么？

Answer 1

首先,Amazon SQS是一个伪队列,这意味着每个消息(如果它到达队列)的传递是有保证的,但不是以通常在队列中发生的FIFO方式.

如果消息的顺序对您很重要,并且您希望队列以FIFO方式工作,则Amazon SQS文档会声明在您的应用程序逻辑中处理此问题,因为来自Amazon SQS的消息将不按顺序到达您.

与此相比,据我所知,您可以在RabbitMQ中实现工作队列.如果这使您无法在应用程序级别实现队列消息排序,那么这将是更优选的选项.

以下几个因素可帮助您确定选择哪一个:

1. 队列消息序列如上所述.

2. 您可以使用RabbitMQ设置自己的服务器,但不能在Amazon SQS的情况下设置,因此这里涉及成本.

3. 设置您自己的服务器需要对主题有很好的了解,这样您就不会保持任何角落不受影响.亚马逊SQS的情况并非如此,因为它很快就开始使用.

4. 您自己的RabbitMQ服务器意味着维护成本低于亚马逊SQS的情况.

更新:

1. Amazon SQS现在支持FIFO队列.

Answer 2

SQS将是我对RabbitMQ的偏好,这就是原因.

1. SQS是一项托管服务.因此,您不必担心运行消息传递系统的操作方面,包括管理,安全性,监控等.亚马逊将为您执行此操作,并在出现问题时提供支持.
2. SQS是弹性的,可以扩展到非常大的速率/数量(根据AWS无限制;))
3. SQS的可用性有很多9个,并且由亚马逊支持,这在您的应用程序中不用担心.

然而,RabbitMQ可能会为put和gets提供更快的响应时间,通常是我的测试中的数万个TPS.要使SQS提供这种吞吐量,您必须使用多个实例进行水平扩展.因此,如果您正在寻找低于5ms的看跌期权,RabbitMQ可能是一个可以考虑的选择,因为我已经看到接近20ms-30ms的时间来我的SQS测试在1000s的TPS,这略高于RabbitMQ.

我们刚刚将我们的消息传递基础架构从ActiveMQ转移到了SQS,并且更加快乐.我们发现它比在云中维护我们自己的ActiveMQ集群便宜.

希望这可以帮助!让我们知道怎么回事..

Answer 3

实际上，我在合理的商业环境中都使用了两者。

简短的答案是，除非有特殊情况，否则最好使用AWS SQS。（您可以跳到底部进行简单总结）

编码（并列）：RabbitMQ和AWS SQS都有建立库和大量示例。

可见性超时（SQS）：SQS通过RabbitMQ提供的一件事是更广泛的可见性超时概念。在RabbitMQ中，如果消费者在确认之前死亡，则会将消息放回到队列中。但是SQS具有更广泛的可见性超时概念，它与特定的呼叫者无关。因此，您可以开始一个工作单元，设置可见性并设置较大的超时时间（最多12小时），断开连接，让另一个工作人员完成并确认。在我的设计中，我们广泛利用了这一点，并消除了额外的服务/存储来管理潜在的较大的“进行中”负载。

死信处理（RabbitMQ-由“兔子”负责）SQS提供基本的死信处理，即所谓的“重新驱动策略”，该策略将邮件转储到死信队列（只是另一个队列）中。它是基本的，仅具有消息计数的概念。RabbitMQ具有“死信交换”功能，可提供过期消息时将消息推送到DLE的功能。但这有点像“如果您不看您的服务并且消息过期，那么它将落入DLE”的想法。对于RabbitMQ来说，这是一个微不足道的胜利，因为我发现这种说法很直观。为什么要监视队列而不是服务？（如果有的话，反之亦然）

管理（SQS）：没有对SQS的管理。您只需为API调用付费。所有常见的头痛问题（例如OS / app安全补丁，扩展（添加更多节点），磁盘）都由AWS团队处理。它还符合FedRamp（供政府使用）。这确实是一个“设置并忘记”系统。RabbitMQ需要通常的OS /服务补丁，AMI，集群，安全性增强等功能。在极少数情况下，AMI可能会崩溃，或者有时需要移动，因此需要开箱即用的集群。SQS消除了所有这些麻烦。

成本（SQS）：单个SQS API调用可以包括“最多10条消息/ 256k大小的批处理”，而“长轮询”可以大大降低成本。此外，还有诸如消息压缩之类的策略，可以在单个有效负载中发送数十条消息（有些声称有数百条或更多条消息），以进一步降低成本。这是在我们考虑人们花费时间进行监视/修补/修复问题之前的时间。SQS也非常适合“ POC项目”，就像它闲置一样，没有成本。

FIFO（TIE）：在2016年，AWS引入了FIFO支持，每百万个api调用需支付约0.01美元的额外费用（0.05美元对每百万个API总计0.04美元-折扣前）。您可以选择是否使用FIFO。对于非FIFO，我们很少看到重复的消息。

存储（SQS）：AWS不收取存储费用，但您有14天的限制。在RabbitMQ上，您将不得不分配，扩展和管理需要峰值存储容量以及额外缓冲区的磁盘空间。只是更让人头疼。

指标（SQS）：SQS提供了现成的指标。尽管您可以将它们添加到AWS中，但要做的只是更多工作。

本地开发人员（领带）：大多数现代商店都喜欢具有本地环境。现在有几个选项允许RabbitMQ和SQS的泊坞窗。

高吞吐量/非常大的消息（RabbitMQ-某种程度）当您按SQS> 1000请求/秒时，SQS的等待时间将增加。有几种解决方法。但是我发现这些情况极为罕见，因为大多数工作都可以划分为多个队列。但是对于需要100k / sec的这类情况，我认为Kafka更好。（我们在工作中也使用Kafka）很少有单个工作单元需要1000+请求/秒且低延迟。*有关此说明，请参见下文

简介：如果您打算加入AWS并愿意与AQS结婚，那么SQS毫无疑问。但您应该继续阅读，因为要考虑一些重要的事情。

RabbitMQ（和其他队列）的经典策略是创建针对某些工作类型优化的几种类型的队列。然后对每个队列进行微调，并将相似的工作分组为少量（通常非常大）的队列。由于SQS没有管理开销，因此实际上最好为每个工作分配专用队列。这样，它既可以扩展规模，又可以消除队列饱和（使队列饱和并使其他工作人员淹没的工作），更好地查看工作（默认指标）等等。

新策略使我的团队可以更好地了解工作的分配方式。“升级实例以增加负载”的日子已经一去不复返了。在过去，我们会看到一个巨大的无法解释的峰值，这会对其他服务产生副作用，或者只是猜测累积数量看起来恰到好处。既然流量已经分离，我们实际上发现了许多以前没有注意到的问题，并且可以清楚地说明往哪里流了多少流量。尽管非常有可能实施指标和工具，但SQS提供了所有现成的功能。

在很多情况下，应认真考虑RabbitMQ

- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.

Answer 4

如果您对成本敏感，Amazon SQS 的成本可能更高。我说可能是因为您仍然需要在某处托管您的 RabbitMQ 服务器。SQS 为您提供前一百万个免费请求，之后每百万个请求收费 0.4 美元。通过启用长轮询，即将您的 receive_message_wait_time 设置为 20 秒，有一个技巧可以降低 SQS 的成本。这并不意味着您的消息只会每 20 秒发送一次，而是意味着如果您的 que 为空（每 20 秒），SQS 不会向您收取“请求”费用。

如果您每小时使用 1000 个请求，那么您每月会看到 744000 个请求。免费层内免费，层外大约 0.74*$0.4 = 0.2976 美元。您可以通过启用等待时间进一步减少。因此，在您的情况下，SQS 实际上可能会更便宜，因为大多数托管从最低 5 美元以上开始（除非您有来自 AWS 的 EC2 免费套餐）。您应该可以选择最小的选项，因为 RMQ 只推荐大约 128mb ram 开始。

如果您愿意，我发现 SQS 对用户更加友好，而 RabbitMQ 则更具技术性。

更新：

我实际上发现 AWS Simple Notification Service 更适合我需要的/sf/answers/958490431/，主要是因为它是基于推送的，即不轮询