我需要创建一个队列进行处理。队列本身的体积相对较小。每小时可能有大约1,000次写入。每个任务的执行可能大约需要一分钟，并且几乎在项目添加到队列后立即处理。
我是否有理由想要实施RabbitMQ而不是像Amazon SQS那样现成的东西？应用程序需要自己的排队系统而不是SQS之类的原因是什么？
答案 0 :(得分：62)
首先，Amazon SQS是一个伪队列，这意味着每条消息（如果它到达队列）的传递是有保证的，但不是以通常在队列中发生的FIFO方式。
如果消息的顺序对您很重要，并且您希望队列以FIFO方式工作，则Amazon SQS文档会声明在您的应用程序逻辑中处理此消息，因为来自Amazon SQS的消息将不按顺序到达您。
与此相比，据我所知，您可以在RabbitMQ中实现工作队列。如果这使您无法在应用程序级别实现队列消息排序，那么这将是更好的选择。
以下几个因素可帮助您决定选择哪一个：
如上所述的队列消息序列。
您可以使用RabbitMQ设置自己的服务器，但不能在Amazon SQS的情况下设置，因此这里涉及成本。
设置自己的服务器需要对主题有充分的了解，这样才不会留下任何角落。亚马逊SQS的情况并非如此，因为它很快就开始使用。
您自己的RabbitMQ服务器意味着维护成本低于亚马逊SQS的情况。
<强>更新
答案 1 :(得分：49)
SQS将是我对RabbitMQ的偏好，这就是原因。
然而，RabbitMQ可能会为放置和获取提供更快的响应时间，通常是我测试中的数千个TPS。要使SQS提供这种吞吐量，您必须使用多个实例进行水平扩展。因此，如果您正在寻找5ms以下的看跌期权，RabbitMQ可能是一个可以考虑的选择，因为我已经看到接近20ms-30ms的时间从我的SQS测试中获得1000的TPS，这略高于RabbitMQ。
我们刚刚将我们的消息传递基础架构从ActiveMQ转移到了SQS，并且更加快乐。我们发现它比在云中维护我们自己的ActiveMQ集群便宜。
希望这有帮助！让我们知道它是怎么回事......
答案 2 :(得分：13)
我实际上在合理的商业环境中使用过这两种方式。
简而言之，除非有特殊情况，否则最好使用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并愿意与SQS结婚，那么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.
答案 3 :(得分：4)
如果您对成本敏感，那么Amazon SQS的价格可能会更高。我说的可能是因为您仍然需要在某个地方托管RabbitMQ服务器。 SQS免费为您提供前100万个请求，然后每百万个请求收取0.4美元。尽管可以通过启用长时间轮询（即将receive_message_wait_time设置为20s）来降低SQS的成本，但这是一个技巧。这并不意味着您的消息每20秒发送一次，而是意味着如果您的查询为空（每20秒），SQS不会向您收取“请求”。
如果您每小时使用1000个请求，那么您每月需要744000。免费套餐内免费，套餐外约0.74 * $ 0.4 = $ 0.2976。您可以通过启用等待时间来进一步减少这种情况。因此，在您的情况下，SQS可能实际上更便宜，因为大多数托管的最低起价为$ 5 +（除非您拥有AWS的EC2免费套餐）。您应该选择最小的选项就可以了，因为RMQ建议仅在128mb内存左右开始。
如果您愿意的话，我发现SQS更加易于使用，RabbitMQ更具技术性。
更新：
我实际上发现AWS Simple Notification Service更适合我的需求https://stackoverflow.com/a/13692720/5403449，主要是因为它是基于推送的，即不轮询