我有一个 Symfony2 应用程序，在某些情况下它必须发送超过 10.000 条推送和电子邮件通知。
我开发了一个 SQS 流程，其中一些工作人员轮询队列以发送电子邮件和移动推送通知。
但是现在，我遇到的问题是，在请求/响应周期中，我需要将此任务/作业（可能不是那个数量）发送到 SQS，此任务本身会消耗大量时间（通常会达到响应超时)。
我是否应该在后台处理此任务（我需要快速回复）？以及如何处理这种情况下可能出现的错误？
注意：Amazon SQS 可以在一个请求中接收 10 条消息，我已经在使用这种方法。也许我应该构建一个包含大量通知作业（最大 256K）的简单 SQS 消息，以向 SQS 发送更少的 HTTP 请求？
【问题讨论】：
标签： php performance symfony amazon-web-services amazon-sqs
当您有一个触发 10k 个操作的操作时，您需要尝试找到一种方法来告诉用户“好的，我知道了。我会开始处理它并在完成时通知您”。
因此，要将这项工作带入后台，应该从您的用户的操作中引发一个域事件，该事件将排队到 SQS 中。用户收到通知，然后工作人员可以从队列中提取该消息并开始发送电子邮件并将通知推送到另一个队列。
归根结底，每批 10 条消息中的 10k 条消息只是对 SQS 的 1k 条请求，无论如何这应该很快。
尽量让你的消息保持小。不要将电子邮件的全部内容发送到队列消息中，因为那样会导致不必要的长延迟。将内容保存在可访问的地方，或者在使用消息时再次查询，而不是在网络上上下传递大内容。
【讨论】：
以及如何处理这种情况下可能出现的错误？
亚马逊为此提供了dead letter queues。在我构建的异步系统中，我通常会创建一个队列，然后向它附加一个重新驱动策略，上面写着“如果我在这个队列上看到相同的消息 10 次，将它发送到死信队列，这样它就不会反弹永远在队列和消费者之间来回切换”。死信队列只是另一个队列。
从死信队列中，您可以决定如何处理未处理的数据。由于在您的情况下是通知（电子邮件或推送通知），因此您的系统中可能有另一个组件会定期重新处理死信队列。 Scheduled Lambdas 对此有好处。
【讨论】：