我需要创建一个队列进行处理。队列本身的数量相对较少。每小时可能有大约1000次写入。每个任务的执行可能需要大约一分钟，并且几乎在将项目添加到队列后立即进行处理。
有什么理由让我想要实施RabbitMQ而不是像Amazon SQS这样的现成产品吗？为什么应用程序需要其自己的排队系统而不是诸如SQS之类的原因有哪些？
我需要创建一个队列进行处理。队列本身的数量相对较少。每小时可能有大约1000次写入。每个任务的执行可能需要大约一分钟，并且几乎在将项目添加到队列后立即进行处理。
有什么理由让我想要实施RabbitMQ而不是像Amazon SQS这样的现成产品吗？为什么应用程序需要其自己的排队系统而不是诸如SQS之类的原因有哪些？
Answers:
首先，Amazon SQS是伪队列，这意味着可以保证每条消息（如果到达队列）的传递，但不能以通常在队列中发生的FIFO方式传递。
如果消息的顺序对您很重要，并且您希望队列以FIFO方式工作，那么Amazon SQS文档会在您的应用程序逻辑中声明要处理此问题，因为来自Amazon SQS的消息将不按顺序到达您。
与此相比，据我所知，您可以在RabbitMQ中实现工作队列。如果这样使您无需在应用程序级别实现队列消息排序，那么这将是更可取的选择。
以下是一些因素可以帮助您决定选择哪一个：
如上所述的队列消息序列。
您可以使用RabbitMQ设置自己的服务器，但对于Amazon SQS则不能，因此此处涉及成本。
设置您自己的服务器将需要对该主题有充分的了解，以便您不遗余力。Amazon SQS并非如此，因为它很快就可以开始使用。
您自己的RabbitMQ服务器意味着线下的维护成本，而Amazon SQS则不然。
更新：
我会选择SQS，而不是RabbitMQ，这就是为什么。
但是，RabbitMQ可能会为放置和获取提供更快的响应时间，通常从我的测试中可以得到成千上万的TPS。为了使SQS提供这种吞吐量，您将不得不水平扩展多个实例。因此，如果您正在寻找5ms以下的看跌期权，可能会考虑使用RabbitMQ，因为我在1000秒TPS时进行SQS测试时已经看到接近20ms-30ms的放置时间，这略高于RabbitMQ。
我们只是将消息传递基础结构从ActiveMQ迁移到了SQS，再也没有比这更快乐了。我们发现它比在云中维护我们自己的ActiveMQ集群便宜。
希望这可以帮助！让我们知道怎么回事..
实际上，我在合理的商业环境中都使用了这两种方法。
简短的答案是，除非有特殊情况，否则最好使用AWS SQS。（您可以跳到底部进行简单总结）
编码（关系）：RabbitMQ和AWS SQS都有建立库和大量示例。
可见性超时（SQS）：SQS通过RabbitMQ提供的一件事是更广泛的可见性超时概念。在RabbitMQ中，如果消费者在确认之前死亡，则会将消息放回到队列中。但是SQS具有更广泛的可见性超时概念，它与特定的呼叫者无关。因此，您可以启动一个工作单元，设置可见性并设置较大的超时时间（最多12小时），断开连接，让另一个工作人员完成并确认。在我的设计中，我们广泛利用了这一点，并消除了额外的服务/存储来管理潜在的较大的“进行中”负载。
死信处理（RabbitMQ-由“野兔”处理）SQS提供基本的死信处理，即所谓的“重新驱动策略”，该策略将邮件转储到死信队列（只是另一个队列）中。它是基本的，仅具有消息计数的概念。RabbitMQ具有“死信交换”功能，可提供过期消息时将消息推送到DLE的功能。但这有点像“如果您不看您的服务并且消息过期，那么它将落入DLE”的想法。对于RabbitMQ而言，这是一个微不足道的胜利，因为我发现这种说法很直观。为什么要监视队列而不是服务？（如果有的话，反之亦然）
管理（SQS）：没有对SQS的管理。您只需为API调用付费。所有常见的麻烦，例如OS /应用程序安全补丁，扩展（添加更多节点），磁盘，都是由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.
如果您对成本敏感，那么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，主要是因为它基于推送，即不轮询