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

【问题标题】：Failure handling for Queue Centric work pattern以队列为中心的工作模式的故障处理
【发布时间】：2017-02-24 02:08:16
【问题描述】：

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

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

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

多个工人，每个工人都有一个单独的队列。因此，如果我有五个工作人员 W1 到 W5，我有 5 个队列 Q1 到 Q5，每个工作人员都知道要从哪个队列读取，并且故障处理类似于一个队列和一个工作人员的情况
一个队列和多个工作人员。这里的失败/重试处理将涉及更多，并且可能最终使用消息队列中的“不可见”时间来确保没有两个工作人员接受同一个工作。必须计算隐身时间，以确保它足以完成作业，但又不足以在很长一段时间后执行重试。

想知道第一种方法是否正确？上述第二种方法中处理故障的稳健方法是什么？

【问题讨论】：

【解决方案1】：

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

这样更好，因为：

如果您担心visibility，您可以先选择默认的timespan，然后如果worker 看起来花费的时间太长，它可以定期调用UpdateMessage() 来更新消息的可见性。

最后，如果您的工作人员超时并且未能完成对消息的处理，它将被其他工作人员再次拾取并重试。您还可以使用消息的DequeueCount 属性来管理重试次数。

【讨论】：

【解决方案2】：

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

使用这种方法，我发现以下问题：

这种方法使您的体系结构紧密耦合（从而超越了使用队列的全部目的）。因为每个 worker 角色都监听一个专用队列，所以负责在队列中推送消息的 web 应用程序总是需要知道有多少 worker 正在运行。每当您扩大或缩小您的工作人员角色时，您需要告诉 Web 应用程序如何开始在适当的队列中推送消息。
如果某个工作角色实例由于某种原因而被删除，则有可能在其他工作角色实例正在其专用队列上工作时，某些消息可能永远不会被处理。
根据 Web 应用程序在队列中推送消息的方式，工作人员角色实例的利用率可能不足/过度使用。为了获得最佳利用率，Web 应用程序应该知道工作人员角色的利用率，以便它可以决定将消息发送到哪个队列。这当然不是 Web 应用程序想要做的事情。

我相信#2 是正确的方法。 @Brendan Green 在他的回答中很好地涵盖了您对 #2 的担忧。

【讨论】：