logo标签列表

SQS与RabbitMQ的比较

amazon-web-servicesrabbitmqamazon-sqs
138

我需要创建一个用于处理的队列。 队列本身是相对低流量的。 每小时可能会有大约1000个写入操作。 每个任务的执行可能需要大约一分钟时间，并且几乎在项添加到队列时立即处理。

是否有任何原因，使我希望使用RabbitMQ而不是像Amazon SQS这样的现成解决方案？ 为什么应用程序需要自己的队列系统而不是类似SQS的东西的原因是什么？

每小时1000次写入是可以的。如果您有时间和足够的知识，那么自己运行RabbitMq实例会节省成本，与亚马逊SQS服务相比也更加经济实惠。对于SQS，它只是存在那里。它很方便、简单，并且编码速度相当快。 - BMW
1
使用 SQS，您可以获得 Lambda 触发器的可扩展性和可伸缩性。 - Daniel Viglione
4个回答
135

以下是一些因素，可以帮助您决定选择哪一个：

  1. RabbitMQ默认采用FIFO。 Amazon SQS队列可以选择设置为FIFO。

  2. 您可以使用RabbitMQ设置自己的服务器，但在Amazon SQS的情况下则不行，这里涉及到成本问题。

  3. 设置自己的服务器将需要良好的主题知识，以便您不会疏漏任何角落。而Amazon SQS则很容易开始使用，无需具备此方面的知识。

  4. 拥有自己的RabbitMQ服务器意味着未来将有维护成本，而这在Amazon SQS中并非如此。

7
您的意思是“Amazon SQS与几乎所有主要平台具有广泛的可移植性，不确定RabbitMQ是否也具备这一特点”。RabbitMQ可以运行在所有主要平台上（Windows、Linux和Mac），并支持多种主流编程语言（Java、.Net、PHP、Python、Ruby等）。 - old_sound
9
@old_sound 两者的区别在于，运行 SQS 时，您只需支付使用费用（发送和接收消息），而运行 RabbitMQ 则需要隐藏成本（在 EC2 使用之上），以确保服务正在运行、监视和修补，包括应用程序和底层操作系统。使用 SQS，AWS 将负责所有这些“无差别的重活”，因此您可以专注于您的应用程序。 - JaredHatfield
40
亚马逊 SQS 现在支持 FIFO。 - rocketspacer
9
请更新帖子顶部以显示它现在支持先进先出队列，当我读到它不支持时，我差点停止阅读。 - andy mccullough
18
这个答案需要一些关注才能变得有用。建议：完全删除FIFO约束，着重于IaaS——扩展、配置等，以及消息传递中的差异（例如轮询）。 - Brett
显示剩余9条评论
95

我更喜欢SQS而非RabbitMQ，原因如下：

  1. SQS是一个托管服务。因此，您不必担心运行消息系统的操作方面，包括管理、安全、监控等。亚马逊将为您完成这些工作，并在出现问题时提供支持。
  2. SQS是弹性的，可以扩展到非常大的速率/容量（根据AWS的说法，没有限制；）
  3. SQS的可用性有很多个9，并由亚马逊支持，这减轻了应用程序中的一项担忧。

然而，根据我的测试结果，RabbitMQ可能会提供更快的put和get响应时间，通常在每秒10万个TPS左右。要使SQS提供这种吞吐量，您需要通过多个实例进行水平扩展。因此，如果您正在寻找低于5ms的put时间，则RabbitMQ可能是要考虑的选项，因为我在1000个TPS的SQS测试中看到了接近20ms-30ms的put时间，略高于RabbitMQ。

我们刚刚将我们的消息基础架构从ActiveMQ转移到了SQS，我们感到非常满意。我们发现它比在云中维护自己的ActiveMQ集群要便宜。

@ssekhar 我们也计划将ActiveMQ迁移到SES..客户端需要进行多大的更改？我们使用Java和最新版本的ActiveMQ。 - Deepak Singhal
我已经运行基于SQS的应用程序多年了，每个put的中位数延迟大约为7毫秒 - 如果您得到20-30毫秒，那么肯定有什么严重问题，可能是在您的测量或测试中。您是否从同一AWS区域/ AZ内运行？您如何进行测量？ - Krease
1
@DeepakSinghal - 我相信您可能已经找到了问题的答案。很抱歉几年后才在这里回答您的问题 :). 从ActiveMQ到SQS - 这里是我们需要处理的一些挑战。1）SQS提供至少一次交付保证，而不是像JMS那样只有一次交付保证，因此我们必须解决重复交付的问题（我们的方法在这里显示-> http://angularthinking.blogspot.com/）。2）SQS使用拉模式而不是像JMS那样将消息推送到客户端，这使得消费更容易。我们实现了自己的监听器和异步传递处理器来简化开发。 - ssekhar
60

我曾经在商业环境中都使用过，并取得了相当的成功。

简短的回答是，除非有特定的角落案例，否则最好选择AWS SQS。（您可以直接跳到底部查看简单摘要）

编码（平局）： RabbitMQ和AWS SQS都有成熟的库和大量的示例。

可见性超时（SQS）： SQS比RabbitMQ提供更广泛的可见性超时概念。在RabbitMQ中，如果消费者在ack之前死亡，则将消息放回队列。但是SQS具有更广泛的可见性超时概念，不与特定的调用方绑定。因此，您可以启动一个工作单元，设置具有较长超时时间（最多12小时）的可见性，断开连接，让另一个工作人员完成并确认它。在我的设计中，我们广泛利用这一点，并消除了管理可能大型“正在进行中”有效载荷的额外服务/存储。

死信处理（RabbitMQ-由'hare'提供） SQS在所谓的“重新驱动策略”中提供基本的死信处理，将消息转储到Dead Letter Queue（只是另一个队列）。它很基本，只有消息计数的概念。RabbitMQ具有Dead Letter Exchanges，当它们过期时，提供将消息推入DLE的功能。但是这有点无关紧要，因为“如果您没有监视您的服务和消息过期，那么它将落入DLE”。对于RabbitMQ来说，这是一个微小的胜利，因为我发现这种论点反直觉。为什么你要监视你的队列而不是你的服务？（如果有什么区别，那就是另一回事）

管理（SQS）： 没有SQS的管理。您只需支付API调用费用。所有通常的头痛，如OS /应用程序安全补丁、扩展（添加更多节点）、磁盘都由AWS团队处理。它还符合FedRamp（用于政府使用）。这真是一个“设置并忘记”的系统。而RabbitMQ需要通常的OS /服务补丁、AMIs、集群、安全硬化等。虽然这很罕见，但AMIs可能会崩溃，或者有时需要移动它们，因此需要开箱即用的集群。SQS消除了所有这些问题。

成本（SQS）： 单个SQS API调用可以包括“批处理最多10条消息/ 256k大小”和“长轮询”，可以大大降低成本。此外，还有像消息压缩这样的策略，可以将数十个（有些声称数百个或更多）消息发送到单个有效载荷中，以进一步降低成本。这还没有考虑人们花费在监视/修补/解决问题上的时间。如果它处于空闲状态，则SQS也非常适合“poc项目”，因为没有成本。

FIFO（平局）： 2016年，AWS引入了FIFO支持，额外收取每百万次API调用约0.10美元的费用（FIFO队列为0.50美元，标准（非FIFO）队列为0.40美元，均不含折扣）。您可以选择使用FIFO或不使用。对于非FIFO，我们很少看到重复的消息。

存储（SQS）： AWS不会收取存储费用，但您有14天的限制。在RabbitMQ上，您将需要分配、扩展和管理磁盘空间，这需要峰值存储容量加上额外的缓冲区。这只会带来更多麻烦。
指标（SQS）： SQS提供开箱即用的指标。虽然您可以将它们添加到AWS中，但这只是更多的工作。
本地开发（平局）： 大多数现代商店都希望拥有本地环境。现在有几个选项允许使用RabbitMQ和SQS的docker。
高吞吐量/非常大的消息（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.
  1. 如果你想推送 > 1000 次/秒的请求，那么请检查 Kinesis。
  2. 如果您不需要微秒级别的速度，可以将非常大的消息体放在 s3 中，并将文件名（键）放在消息体中。
 - Putnik
8
如果你很关注费用的话，Amazon SQS 可能会更昂贵。我这么说是因为你仍然需要在某个地方托管你的 RabbitMQ 服务器。SQS 免费提供了前一百万个请求，之后每一百万个请求收取 $0.4 的费用。但是有一个缩减成本的技巧，就是启用长轮询（即将接收信息等待时间设置为20秒）。这并不意味着您的消息只会在20秒内发送一次，而是意味着如果您的队列为空，则 SQS 不会向您收取“请求”费用（每隔20秒）。
如果您每小时使用1000个请求，那么一个月下来就是 744000。在免费层内是免费的，在超出免费层范围后则为每月大约 $0.74 * $0.4 = $0.2976。通过启用等待时间，您可能还可以进一步降低成本。所以在您的情况下，由于大多数托管服务的最低价格都从 $5+ 开始（除非您有 AWS 的 EC2 免费层），因此 SQS 实际上可能会更便宜。对于 RMQ，只需从128mb RAM 起推荐即可。
根据我的经验，SQS 更加用户友好，而 RabbitMQ 则更加技术化。
更新：
实际上，我发现 AWS 简单通知服务更适合我所需的功能，因为它是基于推送而不是轮询。详情参见https://dev59.com/N2Yr5IYBdhLWcg3wb5vc#13692720。
如果您发送的消息不频繁（例如开发环境），则几乎不需要支付任何费用。空闲的SQS = $0。 - Putnik
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接