Azure 以队列为中心的工作模式的故障处理

我计划在我的一个应用程序中使用以队列为中心的设计。这基本上包括使用Azure队列，其中工作请求从UI排队。工作者从队列中读取、处理和删除消息

工作程序完成的“工作”在事务中，因此，如果工作程序在完成之前失败，则在重新启动时，它会再次拾取相同的消息（因为它尚未从队列中删除），并尝试再次执行该操作（最多重试次数）

要缩放我可以使用两种方法：

多个工人，每个工人有一个单独的队列。因此，如果我有五个worker W1到W5，我有五个队列Q1到Q5，每个worker都知道从哪个队列读取，故障处理与一个队列和一个worker的情况类似

一个队列和多个工人。此处的失败/重试处理将更复杂，并且可能最终使用消息队列中的“不可见”时间来确保没有两个工作人员执行相同的作业。必须计算隐身时间，以确保其足以完成作业，但又不足以在长时间后执行重试

---

想知道第一种方法是否正确吗？在上述第二种方法中，处理故障的可靠方法是什么？

您最好采用方法2—一个队列，但有多个工作人员

这更好，因为：

• 将消息传递到队列的流程只需要了解单个队列端点。这减少了这方面的复杂性
• 现在，扩展从队列中提取的工作人员的数量与任何代码/配置更改都是不耦合的-您可以更轻松地（在运行时）上下扩展

如果您担心

可见性

，您可以首先选择默认的

时间跨度

，然后如果工作人员看起来花费的时间太长，它可以定期调用以更新消息的可见性

---

最后，如果您的工作进程超时并且无法完成消息的处理，则其他工作进程将再次拾取该消息以重试。您还可以使用消息的属性来管理重试次数。

您最好采用方法2—一个队列，但有多个工作者

这更好，因为：

• 将消息传递到队列的流程只需要了解单个队列端点。这减少了这方面的复杂性
• 现在，扩展从队列中提取的工作人员的数量与任何代码/配置更改都是不耦合的-您可以更轻松地（在运行时）上下扩展

如果您担心

可见性

，您可以首先选择默认的

时间跨度

，然后如果工作人员看起来花费的时间太长，它可以定期调用以更新消息的可见性

最后，如果您的工作进程超时并且无法完成消息的处理，则其他工作进程将再次拾取该消息以重试。您还可以使用消息的属性来管理重试次数

多个工人，每个工人有一个单独的队列。所以如果我有五个工人 W1到W5，我有5个队列Q1到Q5，每个工人都知道哪个队列 读取和故障处理与1的情况类似 排队和一名工人

通过这种方法，我看到了以下问题：

• 这种方法使您的体系结构紧密耦合（从而超越了使用队列的全部目的）。由于每个工作者角色侦听一个专用队列，因此负责在队列中推送消息的web应用程序始终需要知道有多少工作者正在运行。无论何时，当您放大或缩小工作角色时，您都可以了解如何告诉web应用程序，以便它可以开始在适当的队列中推送消息
• 如果某个工作人员角色实例由于任何原因被关闭，则可能会在其他工作人员角色实例处理其专用队列时无法处理某些消息
• 根据web应用程序在队列中推送消息的方式，可能存在工作角色实例利用率不足/利用率过高的可能性。为了获得最佳利用率，web应用程序应该知道工作角色的利用率，以便它可以决定向哪个队列发送消息。这当然不是web应用程序所希望做的事情

我认为#2是正确的方式@布伦丹·格林在他的回答中很好地表达了你对#2的担忧

多个工人，每个工人有一个单独的队列。所以如果我有五个工人 W1到W5，我有5个队列Q1到Q5，每个工人都知道哪个队列 读取和故障处理与1的情况类似 排队和一名工人

通过这种方法，我看到了以下问题：

• 这种方法使您的体系结构紧密耦合（从而超越了使用队列的全部目的）。由于每个工作者角色侦听一个专用队列，因此负责在队列中推送消息的web应用程序始终需要知道有多少工作者正在运行。无论何时，当您放大或缩小工作角色时，您都可以了解如何告诉web应用程序，以便它可以开始在适当的队列中推送消息
• 如果某个工作人员角色实例由于任何原因被关闭，则可能会在其他工作人员角色实例处理其专用队列时无法处理某些消息
• 根据web应用程序在队列中推送消息的方式，可能存在工作角色实例利用率不足/利用率过高的可能性。为了获得最佳利用率，web应用程序应该知道工作角色的利用率，以便它可以决定向哪个队列发送消息。这