Azure 队列唯一消息

发布于 2024-11-09 12:29:17 字数 44 浏览 0 评论 0原文

我想确保不会多次将消息插入队列。我可以使用任何 ID/名称来强制唯一性吗?

I would like to make sure that I don't insert a message to the queue multiple times. Is there any ID/Name I can use to enforce uniqueness?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

森罗 2024-11-16 12:29:17

vtortola 几乎涵盖了它,但我想添加更多细节来解释为什么它至少一次交付。

当您读取队列项目时,它不会从队列中删除;而是会被删除。相反,它变得不可见,但保留在队列中。该隐形时间默认为 30 秒(最长:2 小时)。在此期间,将项目从队列中取出的代码有足够的时间来处理队列消息中的任何命令并删除队列项目。

假设队列项在超时时间到达之前被删除,则一切正常。但是:一旦达到超时时间,队列项将再次变得可见,并且保存队列项的代码可能不再删除它。在这种情况下,其他人可以读取同一队列消息并重新处理该消息。

由于队列消息可能会超时,并且可能会重新出现:

  • 您的队列处理必须幂等 - 对队列消息的操作必须产生相同的结果(例如渲染照片的缩略图) )。
  • 您需要考虑超时调整。您可能会发现命令有效,但处理时间太长(也许您的 45 秒缩略图渲染代码工作得很好,直到有人上传 25MP 图像)
  • 您需要考虑有害消息 - 那些永远无法正确处理的消息。也许它们会导致抛出异常,或者有一些无效条件导致消息处理器中止处理,从而导致消息最终重新出现在队列中。有一个名为 DequeueCount 的属性 - 考虑在读取队列项时查看该属性,如果等于 3,则将消息推送到表或 blob 中并向自己发送通知以花一些时间进行调试该消息离线。

有关 get-queue 低级 REST API 的更多详细信息,请参见此处。这将使您更深入地了解 Windows Azure 队列消息处理。

vtortola pretty much covered it, but I wanted to add a bit more detail into why it's at least once delivery.

When you read a queue item, it's not removed from the queue; instead, it becomes invisible but stays in the queue. That invisibility period defaults to 30 seconds (max: 2 hours). During that time, the code that got the item off the queue has that much time to process whatever command was in the queue message and delete the queue item.

Assuming the queue item is deleted before the timeout period is reached, all is well. However: Once the timeout period is reached, the queue item becomes visible again, and the code holding the queue item may no longer delete it. In this case, someone else can read the same queue message and re-process that message.

Because of the fact a queue message can timeout, and can re-appear:

  • Your queue processing must be idempotent - operations on a queue message must result in the same outcome (such as rendering a thumbnail for a photo).
  • You need to think about timeout adjustments. You might find that commands are valid but processing is taking too long (maybe your 45-second thumbnail rendering code worked just fine until someone uploaded a 25MP image)
  • You need to think about poison messages - those that will never process correctly. Maybe they cause an exception to be thrown or have some invalid condition that causes the message processor to abort processing, which leads to the message eventually re-appearing in the queue. There's a property callded DequeueCount - consider viewing that property upon reading a queue item and, if equal to, say, 3, push the message into a table or blob and send yourself a notification to spend some time debugging that message offline.

More details on the get-queue low-level REST API is here. This will give you more insight into Windows Azure queue message handling.

随风而去 2024-11-16 12:29:17

Azure 队列不确保消息顺序和消息的唯一性。消息将被“至少处理一次”,但没有什么可以确保它不会被处理两次,因此它不能确保“最多一次”。

您应该准备好两次收到同一条消息。您可以将 ID 作为数据的一部分放入消息正文中。

Azure queues doesn't ensure message order and either message uniqueness. Messages will be processed "at least once", but nothing ensures it won't be processed twice, so it doesn't ensure "at most once".

You should get ready to receive the same message twice. You can put an ID in the body of the message as part of your data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文