我正在尝试为 QA 团队开发一个 UI,他们可以在其中检查队列消息而无需登录 AWS。
为了使这个 UI 更便宜,我只显示前十个队列消息,现在如果 QA 人员在分析队列 masseges 后想要获取更多记录怎么办。
如何在不使用可见性超时选项的情况下从队列中获取接下来的 10 条消息?
我正在尝试为 QA 团队开发一个 UI,他们可以在其中检查队列消息而无需登录 AWS。
为了使这个 UI 更便宜,我只显示前十个队列消息,现在如果 QA 人员在分析队列 masseges 后想要获取更多记录怎么办。
如何在不使用可见性超时选项的情况下从队列中获取接下来的 10 条消息?
听起来您可能希望同时将 SQS 消息临时写入数据库,并让 QA 团队查看数据库中的消息。SQS 没有分页或“下一个 10”的概念——当你从队列中读取消息时,你应该处理并删除它们——然后要求更多。出于 QA 目的,浏览数据库记录可能更好。
如果您想要更多消息,只需向 SQS 询问更多消息。
SQS 知道有人已经获得了前 10 个,但它不知道是你。如果你要求更多,你会得到更多。
在可见性计时器(默认为 30 秒)在您收到的消息上到期之前,您可以反复询问、询问和询问,您将不会再看到相同的消息。这些消息是“在飞行中”——这意味着 SQS 正在等待某人删除它们、修改它们的可见性或等待计时器到期。计时器到期后,您将再次开始看到它们。
每个 SQS 队列允许在不确认、删除或可见性更改的情况下获取多达 120,000 条消息。祝你好运达到这个极限。
我不能使用可见性超时,因为产品正在生产中,我的工具不应阻止实际服务消耗队列消息
我不确定这到底是什么意思。如果您说您的队列的默认可见性超时为 0,那么这里真正的问题是您一开始就做错了。如果您有多个消费者,则默认可见性超时 0 将导致重复消息传递。
查看有关可见性超时的文档。可见性超时是允许消费者在不删除消息或更改其可见性超时的情况下保留消息的时间,然后才能将其传递给另一个消费者。它不会延迟尚未使用的消息的可用性,或已使用且超时已过或已重置的消息的可用性。
如果您想在不阻塞应用程序的情况下检查消息,请从队列中获取它们,根据需要发送尽可能多的请求(发出多个请求,如果超过 10 个),然后立即发送 API 请求以将可见性超时设置为 0对于那些消息。这将立即释放它们以供应用程序再次使用(当然,如果应用程序积压,则由该工具使用)。
替代方案:对于队列消息分析的真正独立路径,我使用不同的方法:SNS Fanout。
我不是消息生产者直接将消息发送到 SQS,而是将它们发送到 SNS 主题。主队列和辅助队列都是该主题的订阅者。应用程序从主队列中消费,而辅助队列只是坐在那里收集每条消息的第二个副本。当辅助队列中的消息过期时,它们就会消失(默认 = 4 天)。这为我提供了一个非常有用的工具来进行故障排除以及处理应用程序使用者中导致消息处理不当的任何灾难性事件,其中从 SQS 接收的消息随后由于意外或未处理的情况而丢失。
您必须删除前 10 条消息,否则它们将继续被退回。甚至可能会返回已删除的消息,因此您的系统能够处理重复消息非常重要。