0

使用多个工作人员处理程序代码与处理整个负载相比，是否有任何内在优势？

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

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

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

如果我们只关心正在完成的工作（在第 5 步完成），那么它的扩展方式似乎是相同的（一旦您使用至少 3 个工作人员）。也许这项大工作会更好，因为具有这种设置的工人的瓶颈问题较少？

4

2 回答 2

1

一般来说，作业越小，当某些进程崩溃时，您损失的工作就越少。此外，作业越小，您能够越均匀地分配工作。（而不是在某一时刻让一个工作实例做长时间的工作而所有其他工作都闲置，你会让所有工作实例做一些小工作。）

抛开如何将工作分解成更小的部分，一个问题是是否应该有多个工作角色，每个角色只能做一种工作，或者一个工作角色（但很多情况下）可以做所有事情。我会默认使用后者（可以做所有事情的代码，只需检查所有队列以查看需要做什么），但有理由选择前者。例如，如果您需要更多 RAM 来完成某项工作，则可以为该工作人员使用更大的 VM 大小。另一个例子是，如果您想独立扩展不同类型的工作。

于 2010-05-19T21:37:57.213 回答
1

添加到@smarx 所说的内容：

  • “多用途”工人的模型当然更普遍。因此，即使您需要专门的类型（如上面使用的额外 RAM 示例），您也只需在该特定角色中执行一个任务。

  • 还有额外的成本视角。您将有经济动机来增加“任务密度”（如在任务/实例中）。如果您有M种类型的工作，并且您将每种类型分配给不同的工人，那么您将为M种实例付费，即使其中一些可能只是偶尔做一些工作。

我前段时间写过这个，这是我们指南的一个主题（“06 week3.docx”章）

许多框架和示例（包括我们的）都使用这种方法。

于 2010-05-27T18:26:26.713 回答