Windows Azure工作者角色：一个大工作或许多小工作？

Question

使用多个工作程序处理过程代码而不是处理整个负载时，是否有任何固有的优势？

换句话说，如果我的工作流程如下：

1. 从queue0获取工作并执行A
2. 将结果存储在队列1中的A
中
3. 从队列1获取结果并执行B
4. 将队列B中的结果存储在队列2中
5. 从queue2获取结果并执行C

使用3名工人自己完成整个过程是否有固有的优势？3名工人各自完成工作的一部分（工人1做1＆amp; 2，工人2做3＆amp; 4，工人3做5）。

如果我们只关心完成工作（完成第5步），它似乎会以相同的方式扩展（一旦你使用至少3名工人）。也许大工作更好，因为有这种设置的工人有更少的瓶颈问题？

Answer 1

通常，作业越小，某些进程崩溃时丢失的工作就越少。此外，作业越小，您就能够更均匀地分配作业。 （而不是一次让一个工作者实例执行一个很长的工作而其他所有工作都空闲，你将让所有工作者实例做一些小工作。）

撇开如何将工作分解成更小的部分，存在一个问题：是否应该有多个工作者角色，每个角色只能做一种工作，或者一个工人角色（但很多实例）可以做任何事。我会默认使用后者（代码可以执行所有操作并只检查所有队列以查看需要执行的操作），但有理由选择前者。例如，如果您需要更多RAM用于某种工作，则可能会为该工作人员使用更大的VM大小。另一个例子是如果你想独立地扩展不同类型的工作。

Answer 2

添加@smarx所说的内容：

• “多用途”工作者的模型当然更为通用。因此，即使您需要特殊类型（例如上面使用的额外RAM示例），您也只需要在该特定角色中执行单个任务。

• 还有额外的成本视角。您将有经济激励来增加“任务密度”（如在任务/实例中）。如果您有 M 类型的工作，并且您将每个工作分配给不同的工作人员，那么您将支付 M 实例，即使某些实例每次只能执行一些工作不一会儿。

我前一段时间blogged about this这是我们guide的一个主题（章节“06 week3.docx”）

许多框架和样本（包括我们的）使用这种方法。