1

我有两个工人角色的实例。

我只想在其中一个 Worker Role 实例上运行子任务（在线程池线程上）。

我最初的想法是做这样的事情：

ThreadPool.QueueUserWorkItem((o) =>
{
    if (RoleEnvironment.CurrentRoleInstance.Id == RoleEnvironment.Roles[RoleEnvironment.CurrentRoleInstance.Role.Name].Instances.First().Id)
    {
        emailWorker.Start();
    }
});

但是，上面的代码依赖于Role.Instances集合总是以相同的顺序返回实例。是这样吗？或者可以按任何顺序退回物品吗？

是否有另一种仅在一个角色实例上运行任务的批准方式？

4

2 回答 2

1

Joe, the solution you are looking for typically rely on:

  • either acquiring on lease (similar to a lock, but with an expiration) on a specific blob using the Blob Storage as a synchronization point between your role instances.
  • or queuing / dequeuing a message from the Queue Storage, which is usually the suggested pattern to delay long running operations such as sending an email.

Either ways, you need to go through the Azure Storage to make it work. I suggest to have a look at Lokad.Cloud, as we have designed this open-source framework precisely to handle this sort of situations.

于 2010-02-06T10:39:59.697 回答
0

如果他们需要做不同的事情，那么在我看来，您没有 2 个单个工作者角色的实例。实际上，您有 2 个不同的工人角色。

尤其是在查看应用程序的可伸缩性时，进程需要能够在多个实例上运行。当您只想在一个角色上运行的任务变得足够大以至于需要扩展到 2 个或更多角色实例时会发生什么？

为 Azure 开发的好处之一是，如果您正确设计应用程序，您将自动获得可伸缩性。如果让你额外工作以获得不可扩展的东西，这就是你想要做的。

是什么触发了此任务的启动？如果您在队列存储上使用消息（如 Joannes 所建议的那样），那么只有一个工作人员角色会接收并处理该消息，而您的工作人员角色的哪个实例执行此操作并不重要。

因此，目前，如果您有一个执行子任务的辅助角色和另一个执行其他所有操作的辅助角色，只需将 2 个辅助角色添加到您的 Azure 解决方案。但是，即使您这样做，处理子任务的工作角色也应该以这样的方式编写，即如果您将其扩展为运行多个实例，它将正常运行。在这种情况下，您不妨坚持使用单个工作者角色和代码来处理队列中的消息以启动您的子任务。

于 2010-04-15T18:10:13.030 回答