【问题标题】:AWS SQS queue improve performanceAWS SQS 队列提高性能
【发布时间】:2017-06-08 15:31:16
【问题描述】:

我尝试实施 AWS SQS 队列以最小化来自后端服务器的数据库交互,但我遇到了问题。

  • 我有一个消费者进程从一个 SQS 队列中查找消息。
  • 当客户端单击 Web 界面中的按钮时,会在 SQS 队列中放置一条 JSON 消息。
  • 应用服务器中的后端作业从 SQS 队列中提取 JSON 消息,从队列中删除该消息并进行处理。

为了测试功能,我为一个客户端实现了逻辑。它运行良好。但是,当我再添加 3 个客户端时,它无法正常工作。我可以看到 SQS 队列被 500 条消息卡住了,并且后端作业正在从队列中正常读取。

我需要增加后端作业的数量还是增加客户端 SQS 队列的数量?现在所有客户端都将消息发送到同一个队列。

如何计算所需的后端作业数量?另外,是否有任何设置可以让 SQS 工作得更快?

【问题讨论】:

  • 我们需要更多信息——我已经通过 SQS 推送了数百条消息/秒,没有任何问题。需要代码/详细信息。
  • 你是什么意思“卡住了 500 条消息”?究竟是什么不在这里工作?您是说不能将消息添加到队列中吗? SQS 队列只存储消息。 SQS 没有做任何“工作”,所以我不明白你说的让它“工作得更快”是什么意思。您可以像这样计算所需的后端作业数量:如果队列中的项目没有得到您希望的处理速度,请添加更多工作人员。
  • 非常感谢您提供的信息。想知道每秒可以存储的消息数量有什么限制。似乎没有限制会添加更多工作线程并检查一下。
  • 新的 FIFO 队列只有吞吐量限制。如果您使用的是标准队列,它应该能够每秒处理几乎无限的消息。但即使是 FIFO 队列也有每秒 300 条消息的吞吐量,这听起来比您所经历的要高得多。
  • 非常感谢您提供的详细信息。我可以在 aws 控制台中看到一段时间内的任何指标可以表明我增加了消费者吗?目前,如果客户正在等待,我将增加消费者。我有兴趣了解有关 SWF 的更多信息。如果您可以分享任何好的视频链接,就像我看到的大多数讨论理论部分的视频一样,如何创建 swf,那就太好了?

标签: amazon-web-services amazon-sqs


【解决方案1】:

将消息存储在队列中很好 - 事实上,这就是使用队列的目的。

如果您的后端系统无法以生成消息的速度使用消息,则队列将充当缓冲区以保留消息,直到可以处理它们为止。一个很好的例子是这个 AWS re:Invent 演示文稿,其中显示了一个包含超过 2 亿条消息的队列:Building Elastic, High-Performance Systems with Amazon SQS and Amazon SNS

如果快速处理消息很重要,那么扩展您的消费者以匹配消息产生的速度(或更快,以便您可以消耗积压)。

您提到您的进程“从 SQS 队列中提取 JSON 消息,从队列中删除消息并对其进行处理”。请注意,最佳做法是从队列接收消息,对其进行处理并然后将其删除(在完全处理之后)。这样,如果您的进程失败,消息将在定义的不可见期后自动重新出现在队列中。这使您的应用程序对故障更具弹性。

【讨论】:

  • 非常感谢您提供的信息。将观看视频链接。目前,如果客户正在等待,我将增加消费者在 aws 控制台中我可以看到一段时间内的任何指标可以指示我增加消费者吗?我有兴趣了解更多关于 SWF 的信息。如果您可以分享任何好的视频链接,就像我看到的大多数讨论理论部分的视频一样,如何创建 swf,那就太好了?
  • Amazon CloudWatch 具有有关 Amazon SQS 队列中消息数量的指标。这些指标可与 Auto Scaling 一起使用,以在队列增长超过所需大小时自动增加容量。请参阅:Monitoring Amazon SQS using CloudWatch 对于 Amazon Simple Workflow (SWF),请查看 AWS Reinvent video
  • 对延迟回复表示歉意。非常感谢
猜你喜欢
  • 2020-05-08
  • 2016-08-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-01-13
  • 1970-01-01
  • 2016-04-13
  • 1970-01-01
相关资源
最近更新 更多