Windows Azure 工作者角色：一项大工作还是许多小工作？
使用多个工作线程处理程序代码片段与处理整个负载相比是否有任何固有的优势？
换句话说，如果我的工作流程如下所示：
- 从队列 0 获取工作并执行 A
- 将 A 的结果存储在队列 1 中 从队列
- 1 获取结果并执行 B
- 将 B 的结果存储在队列 2 中
- 从队列 2 获取结果并执行 C
是否存在固有优势使用 3 个工作人员，每个工作人员自己完成整个流程，而不是使用 3 个工作人员，每个工作人员完成部分工作（工作人员 1 执行 1 和 2，工作人员 2 执行 3 和 4，工作人员 3 执行 5）。
如果我们只关心正在完成的工作（在步骤 5 中完成），那么它似乎会以相同的方式扩展（一旦您使用至少 3 个工作人员）。也许大工作更好，因为具有这种设置的工人有更少的瓶颈问题？
Is there any inherent advantage when using multiple workers to process pieces of procedural code versus processing the entire load?
In other words, if my workflow looks like this:
- Get work from queue0 and do A
- Store result from A in queue1
- Get result from queue 1 and do B
- Store result from B in queue2
- Get result from queue2 and do C
Is there an inherent advantage to using 3 workers who each do the entire process themselves versus 3 workers that each do a part of the work (Worker 1 does 1 & 2, worker 2 does 3 & 4, worker 3 does 5).
If we only care about working being done (finished with step 5) it would seem that it scales the same way (once you're using at least 3 workers). Maybe the big job is better because workers with that setup have less bottleneck issues?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，作业越小，当某些进程崩溃时丢失的工作就越少。此外，工作越小，您就越能均匀地分配工作。 （而不是在某一时刻让一个工作实例执行一项长时间的工作而所有其他工作实例都闲置，而是让所有工作实例执行小部分工作。）
抛开如何将工作分解为更小的部分不谈，有一种方法是否应该有多个工作者角色（每个工作者角色只能做一种工作），或者是否应该有一个工作者角色（但有很多实例）可以做所有事情。我会默认使用后者（可以执行所有操作的代码，只需检查所有队列以查看需要完成的操作），但有理由选择前者。例如，如果您需要更多 RAM 来完成一种工作，您可以为该工作线程使用更大的虚拟机大小。另一个例子是，如果您想独立扩展不同类型的工作。
In general, the smaller the jobs are, the less work you lose when some process crashes. Also, the smaller the jobs are, the more evenly you'll be able to distribute the work. (Instead of at one point having a single worker instance doing a long job and all the others idle, you'd have all the worker instances doing small pieces of work.)
Setting aside how to break up the work into smaller pieces, there's a question of whether there should be multiple worker roles, each of which can only do one kind of work, or a single worker role (but many instances) that can do everything. I would default to the latter (code that can do everything and just checks all the queues to see what needs to be done), but there are reasons to go with the former. If you need more RAM for one kind of work, for example, you might use a bigger VM size for that worker. Another example is if you wanted to scale the different kinds of work independently.
添加@smarx所说的：
“多用途”工人的模型当然更通用。因此，即使您需要专门的类型（如上面使用的额外 RAM 示例），您也只需在该特定角色中执行一个任务即可。
还有额外的成本因素。您将有经济动机来增加“任务密度”（如任务/实例）。如果您有 M 种工作类型，并且将每个工作类型分配给不同的工作人员，那么您将为 M 个实例付费，即使其中一些实例可能每次只执行一些工作一会儿。
我不久前在博客上讨论过这一点，这是我们的主题之一指南（章节“06 week3.docx”）
许多框架和示例（包括我们的）都使用这种方法。
Adding to what @smarx says:
The model of a "multipurpose" worker is of course more general. So even if you require specialized types (like the extra RAM example used above) you would simply have a single task in that particular role.
There's the extra perspective of cost. You will have an economic incentive to increase the "task density" (as in tasks/instance). If you have M types of work and you assign each one to a different worker, then you will pay for M instances, even if some those might only do some work every once in a while.
I blogged about this some time ago and it is one topic of our guide (chapter "06 week3.docx")
Many frameworks and samples (including ours) use this approach.