Azure 队列和表存储事务最佳实践

发布于 2025-01-03 00:08:50 字数 143 浏览 0 评论 0原文

使用天蓝色表存储,我阅读了有关同一分区内的实体组事务的信息。现在,如果我将 Azure 队列与表存储一起使用会发生什么。是否可以从队列中处理消息,插入到表存储中。如果出现问题,是否需要回滚并将消息再次放入队列?

或者我应该如何使用 Azure 处理这种情况

Using azure table storage I read about Entity Group Transactions within the same partition. Now what happens if I use the Azure Queue together with table storage. Is it possible to get handle a message from the queue, insert into table storage. If something breaks, rollback and put the message on the queue again?

Or how should I handle such a scenario with Azure

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

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

发布评论

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

评论(1

记忆で 2025-01-10 00:08:50

表和队列没有任何关联的事务。

以下是一些常规队列使用指南:

  • 确保队列操作是幂等的 - 也就是说,多次执行队列消息会得到相同的结果,并且会产生可重复的副作用
  • 设置合理的队列消息可见性暂停。如果您的任务看起来需要更长的时间,您可以延长消息的不可见超时时间。这可以防止其他线程/角色实例在您仍在处理同一队列项目时获取该队列项目。
  • 对于长时间运行的任务(或者如果可能的话,您希望避免多次消耗资源的任务),请一路修改队列消息,给自己状态提示。例如:您有一个渲染视频队列消息:'RENDER|Source-URL'。您正在渲染视频,它需要两次通过。您已完成第 1 遍,结果存储在临时 blob 中。您可以使用 'RENDER|Source-URL|Pass1-URL' 等内容修改消息。现在,假设出现问题并且您的渲染任务由于某种原因失败。稍后,当您再次收到此消息时,您可以从第 2 关开始,而不是从头开始。
  • 您无需担心将消息放回到队列中。在您显式删除消息之前,消息实际上不会从队列中删除。它们只是在您选择的不可见超时时间内不可见。如果您未在该期限结束前删除(或延长该期限),则该消息将再次可见以供其他人阅读。 注意:此时,一旦其他人读取了队列消息,原来的消息持有者将无法再删除该消息。

Tables and queues don't have any associated transactions.

Here's some general queue usage guidance:

  • Make sure queue actions are idempotent - that is, you'd have the same results executing a queue message more than once, with repeatable side-effects
  • Set a reasonalbe queue message visibility timeout. If your task looks like it will take longer, you can extend a message's invisibility timeout. This prevents other threads / role instances from grabbing the same queue item while you're still working on it.
  • For long-running tasks (or those where you want to avoid consuming a resource multiple times if possible), modify your queue message along the way, giving yourself status hints. For example: you have a render-video queue message: 'RENDER|Source-URL'. you're rendering video, and it needs two passes. You've done pass 1 with results stored in a temporary blob. You could modify the message with something like 'RENDER|Source-URL|Pass1-URL'. Now, assume something goes wrong and your rendering task fails for some reason. Later, when you pick up this message again, you can start from pass 2, instead of from the very beginning.
  • You don't need to worry about putting messages back on the queue. Messages aren't actually removed from the queue until you explicitly delete them. They simply become invisible during the invisibility timeout period you choose. If you don't delete by the end of that period (or extend the period), the message becomes visible again for someone else to read. Note: At this point, once someone else reads the queue message, the original message-holder will no longer be able to delete the message.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文