多个Azure辅助角色轮询同一队列是否会导致死锁或中毒消息
场景：
如果我使用多个线程分离多个辅助角色或一个辅助角色，这将轮询 Azure 队列中的新消息。
有人可以确认这是否是正确的设计方法吗？我希望拥有许多辅助角色的原因是为了加快 PROCESSJOB 的速度。我们的应用程序应该接近实时，即一旦有消息我们就应该收到，应用复杂的业务规则并提交到 AZURE DB。我们预计每 3 分钟有 11,000 条消息。
谢谢。
Scenario:
if I've spin off multiple Worker roles or ONE Worker role with multiple threads, which polls the new messages in Azure Queue.
Could someone please confirm if the this the correct design approach? The reason I would like to have many worker roles is to speed up the PROCESSJOB. Our application should be near real time, i.e. as soon as there are messages we should get, apply complex business rules and commit to AZURE DB. We are expecting 11,000 message per 3min.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以拥有任意数量的队列读取器。扩展辅助角色实例是很常见的，因为它们都可以从同一个队列中读取，从而为您提供更大的工作吞吐量。
当您读取队列消息时，它会在一段时间内被标记为“不可见”，以防止其他人读取并执行相同的工作。消息的所有者必须在该时间段到期之前将其删除，否则该消息将再次可见，并且当原始读者尝试删除它时将引发异常。这意味着您的操作必须是幂等的。
没有直接的有毒消息处理，但很容易实现，因为每条消息都有一个出队计数。只需检查并阅读3-4遍后即可删除有毒信息。您还可以根据出队计数动态调整超时时间，因为可能由于时间窗口太短而导致处理失败。
这是
DequeueCount的 MSDN 文档。编辑：就 3 分钟内处理 11,000 条消息而言：队列的可扩展性目标是
5002,000 TPS，或 3 分钟内最多处理 360,000 个事务（远远超出您的 11,000 条消息要求）。您可以通过将消息组合到单个队列消息中以及一次读取多条消息来进一步加快速度，这也将减少您的事务计数。您还可以查看 ApproximateMessageCount 队列的属性，以查看您的队列是否正在备份（然后扩展到其他实例以帮助消耗队列 项目）。You may have as many queue-readers as you like. It's very common to scale out worker role instances, as they can all read from the same queue, giving you much greater work throughput.
When you read a queue message, it's marked "invisible" for a period of time, to prevent others from reading and doing the same work. The owner of the message must delete it before the time period expires, otherwise the message becomes visible again, and an exception will be thrown when the original reader attempts to delete it. This means your operations must be idempotent.
There's no direct poison-message handling, but it's easy to implement, as each message has a dequeue count. Just check it and remove poison messages after being read 3-4 times. You can also dynamically adjust the timeout period based on dequeue count, as maybe the processing fails due to too-short a time window.
Here's the MSDN documentation for
DequeueCount.EDIT: As far as processing 11,000 messages in 3 minutes: the scalability target for queues is
5002,000 TPS, or up to 360,000 transactions in 3 minutes (far beyond the 11,000 message requirement you have). You can speed things up further by combining messages into a single queue message, as well as reading multiple messages at a time, which will also reduce your transaction count. You can also look at the ApproximateMessageCount property of a queue to see if your queue is backing up (and then scaling out to additional intstances to help consume queue items).