【发布时间】：2019-11-21 20:36:58
【问题描述】：
我知道 Amazon SQS 有自己的内部最大传输消息数。但是有没有办法让你自己把这个数字设置得更小？例如，假设我不希望任何时候处理超过 10 条消息。
有哪些方法可以实现这一目标？我相信在 RabbitMQ 中有一种类似于shovelling 的方法。我可以有 2 个队列，A 和 B。所有消息将首先发送到A。然后，如果B 中的飞行消息少于 10 条，则该消息将发送到 B。然后消费者将从B消费。
那我得解决A到B的消息何时传输的问题。理想情况下，这将是一个无服务器解决方案。我有几个想法，例如：
CloudWatch 事件 - 鉴于
B中有处理空间，我可以使用 CloudWatch 触发 Lambda 函数（我们称之为ShoveLambda）来移动消息。但最短的轮询时间将是 CloudWatch 设置的最小间隔 60 秒。SNS 主题 除了做 1，我还可以有一个 SNS 主题，在新发布时会触发
ShoveLambda移动消息。当处理B中的消息时，消费者也会向SNS 发布通知，这将触发ShoveLambda，（我也可以让消费者直接调用ShoveLambda，想法？）。这意味着在最坏的情况下，从A到B的消息之间会有60 秒的延迟，但大多数情况下，由于消息在@ 中处理，所以无论如何都会有固定数量的铲子。 987654338@.
关于这种方法的任何想法和想法都会很棒。这种方法好吗？我是否应该将并发 ShoveLambda 执行次数限制为 1？好像同时执行 2 个执行我会铲出我想要的两倍，即使我限制执行，我想仍然可能存在并发问题，但我不太担心是否有太多消息被铲到 B只要它在所需的最大飞行消息或某个上限的 30% 以内。
但在我写这篇文章时，我担心这种方法存在漏洞。
更多信息 我们可能有一些用例可以做到这一点，例如限制客户一次只能运行 10 个作业。但允许服务器独立扩展。执行不同类型的处理。
但我们的主要案例是我们有一个处理文件的工作流程，并且该工作流程中的一个阶段涉及我们无法扩展的单体 Windows 服务器应用程序。我们通过 SOAP API 请求进行交互。它本身以某种方式对作业进行排队，其 SQL 数据库作为应用程序的一部分运行。
这是我们流程中的一个瓶颈，但我们不希望它堆积 100 多个工作。我们拥有处理管道其他部分并与此 SOAP API 交互的容器。它们应该根据传入的文件进行扩展，但我们不希望 Windows 机器上的作业数量一次超过 10 个。
我希望提供足够的上下文。
【问题讨论】：
-
您使用的哪个服务是SQS？标准还是先进先出？
-
您可以做的是，在将新消息添加到队列之前，您可以获取 SQS 中的飞行消息总数。根据您的要求，如果队列中的消息少于 10 条，您可以添加消息，直到计数达到 10 条。这样，您始终可以通过简单的 API 调用在不影响性能的情况下维护 10 条正在进行的消息。
-
您能否告诉我们为什么您要限制机上消息？这通常是处理消息的工作人员的功能。如果您想要更少的飞行，那么只需运行更少的工人。请告诉我们更多关于您的情况，以便我们提供更好的答案。
-
根据要求，更多信息@JohnRotenstein
标签： amazon-web-services aws-lambda amazon-sqs