如何处理SQS应用程序的长期运行消费
我有一项与AWS SQS集成的服务。我们的一些消息需要超过12小时(最大可见度超时)来处理。
在这种情况下,其他消费者在可见性超时后仍将在处理消息仍在处理后接收相同的消息。
我想知道这种情况的最佳做法是什么。我可以在处理消息之前添加删除逻辑,但是在这种情况下,如果第一个消费者未能处理消息,则该消息将不会进入DLQ。
任何建议都将不胜感激!
I have a service which integrate with AWS SQS. Some of our messages take longer than 12 hour(maximum visibility timeout) to process.
In this case, other consumers will pick up the same message after visibility timeout while the message is still being processed.
I am wondering what's the best practice for such cases. I can add de-duplication logic before processing messages but in this case, if the first consumer fail to process the message then the message won't go into DLQ.
Any suggestion would be appreciated!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我相信您可以简单地调用
ChangeMessageVisibility
定期延长超时。aws aws sqs sqs sqs超时解释
提供了一些好的细节。
I believe you can simply have your worker call
ChangeMessageVisibility
periodically to extend the timeout.AWS SQS Visibility Timeout Explained
provides some good details.
最好的做法是不使用SQS(或任何其他队列),而是一项支持长流程的技术。 AWS具有步骤函数 and 简单的工作流程为该特定目的创建。
您还可以考虑使用 temporal.io 这是简单工作流的开源后继者。
The best practice is not to use SQS (or any other queue), but a technology that supports long processes. AWS has Step Functions and Simple Workflow created for that specific purpose.
You can also consider using temporal.io which is an open source successor of the Simple Workflow.