以队列为中心的工作模式的失败处理

Question

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

工作人员完成的'工作'在一个事务中，所以如果工人在完成之前失败，在重新启动时它会再次拾取相同的消息（因为它没有从队列中删除）并尝试执行操作再次（最多重试的最大数量）

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

1. 多位工人每一个单独的队列。所以如果我有五个工人W1到W5，我有五个队列Q1到Q5，每个工人知道从哪个队列读取，并且故障处理与一个队列和一个工人的情况相似
2. 一个队列和多个工人 。这里的失败/重试处理会涉及更多，最终可能会在消息队列中使用“隐形”时间，以确保没有两名工作人员选择相同的工作。必须计算不可见时间，以确保其足以完成工作，但又不足以在很长一段时间后执行重试。

想知道第一种方法是否是正确的方法吗？上述第二种方法处理失败的强大方法是什么？

Answer 1

你会更好地采取方法2 - 一个队列，但与多个工人。

这是更好，因为：

• ，提供消息队列只需要知道一个队列终点的过程。这降低了这方面的复杂性;
• 标定从队列中拉出，现在从任何代码/配置变化解耦工人数 - 你可以放大和缩小更容易（在运行时）

如果你所担心的visibility，最初可以选择默认的timespan，然后如果工作人员看起来需要的时间太长，则可以定期呼叫UpdateMessage()来更新消息的可见性。

最后，如果您的员工超时并未能完成消息的处理，则会由其他员工再次提取以再次尝试。您还可以使用消息的DequeueCount属性来管理重试次数。

Answer 2

多个工人分别拥有一个队列。所以，如果我有五个工人 W1至W5，我有5个队列Q1到Q5和每个工人都知道哪个队列 读取和故障处理是一个 队列，一个工人

随着案情相似这种方法我看到以下问题：

• 这种方法使得你的体系结构紧密耦合（从而击败了使用队列的全部目的）。由于每个工作角色都监听一个专用队列，因此负责推送队列中消息的Web应用程序始终需要知道有多少员工正在运行。任何时候你扩大或缩小你的工作者角色，你都需要告诉Web应用程序，以便它能够开始将消息推送到适当的队列中。
• 如果某个工作者角色实例由于某种原因被关闭，则有可能某些消息可能无法处理，因为其他工作者角色实例正在其专用队列上工作。
• 根据Web应用程序如何在队列中推送消息，可能存在使用/过度使用辅助角色实例的可能性。为了获得最佳利用率，Web应用程序应该了解工作程序角色使用情况，以便它可以决定将消息发送到哪个队列。对于Web应用程序来说，这绝对不是理想的事情。

我相信＃2是正确的路要走。 @Brendan Green很好地回答了他对＃2的回答。