提高 Amazon SQS 性能

Question

我能找到的关于 Amazon Simple Queue Service (SQS) 性能的所有信息，包括他们自己的文档，都表明获得高吞吐量需要多个线程。我已经使用 Node 12 的 JS API 自己验证了这一点。如果我创建多个线程，每个线程上的吞吐量大致相同，因此总吞吐量的增加几乎是线性的。但我在一台有很多内核的好机器上运行它。当我在单核上运行 Lambda 时，多线程并不能提高性能，这通常是我对多线程应用程序的期望。

但这就是我不明白的地方——CPU 的方式应该很少发生，大部分时间都花在等待网络请求上。 AWS SQS API 似乎是异步的，因为所有方法都对响应使用回调，并且我使用 Promises 来“异步化”所有 API 调用，同时运行多个任务。通常，使用任何类型的异步 IO 执行此操作都由 Node 处理得很好，并且极大地提高了吞吐量，我一直使用数据库 API、多个流等来执行此操作。但是 SQS 绝对不是那样的，它的行为好像它的IO 实际上是网络调用上的同步和阻塞线程，这对于任何现代 API 来说都是令人发指的。

有没有人成功地在单个节点线程中获得高 SQS 消息吞吐量？对于 FIFO 队列（发送、接收和删除，所有这些都在调用最大批处理大小为 10 的批处理方法），我看到的最大值约为 50 到 100 条消息/秒。这是在 lambda 中运行的，即在他们自己的网络上，它只比通过 Internet 在我的笔记本电脑上运行它稍微快一点，这是另一个令人惊讶的发现。 Amazon's documentation 说 FIFO 队列在批处理时应该支持每秒最多 3000 条消息，这对我来说很好。真的需要多个内核或虚拟 CPU 上的多个线程来实现这一点吗？那太可笑了，我简直不敢相信会使用那么多CPU，应该主要是IO时间，应该是异步的。

编辑：

随着我继续测试，我发现只有在每个线程处理不同的队列时才会出现线程数的线性改进。如果线程都在处理同一个队列，那么添加线程并没有改善。所以它表现得好像每个队列都被亚马逊限制了。但是它似乎被限制的吞吐量远低于我发现的最大吞吐量。现在真的很困惑和失望！

Answer 1

Michael 对原始问题的回答是正确的。我将所有消息发送到同一个消息组。我之前一直在使用 AMQP 消息队列，其中消息将按照发送顺序在队列中排序，然后按该顺序分发给订阅者。但是当多个侦听器正在使用 AMQP 队列时，由于网络延迟不同，无法保证它们会按时间顺序接收。

所以这实际上是 SQS 的一个非常酷的特性，保证消息将按照它们在同一消息组中发送的顺序按时间顺序接收。就我而言，我不在乎收据订单。所以现在我为每条消息设置一个唯一的消息组 ID，并通过增加异步消息接收循环的数量来提高性能，仍然只是在一个线程中，而且吞吐量非常惊人！

所以底线：如果消息的确切接收顺序对您的 FIFO 队列并不重要，请将消息组 ID 设置为每条消息的唯一值，并通过更多接收者任务进行扩展以获得最佳的吞吐量性能。如果您确实需要有保证的消息排序，那么每秒大约 50 条消息似乎是您能做的最好的了。