4

我正在寻找一种在多个工作角色实例上拥有“单例”模块的方法。我想在 Azure 中有一个具有队列和多个工作角色的并行执行模型。

这个想法是想要一个“主”实例，也就是说检查新数据，并通过将其添加到队列来调度它，处理来自特殊队列的所有消息，其他人没有处理，并将 Blob 存储挂载为虚拟驱动器，具有读/写访问权限。

我将永远只有一个“主实例”。当该主实例由于某种原因出现故障时，已经实例化的另一个实例应该很快被“选举”为主实例（几秒钟）。这应该发生在损坏的实例被 Azure 环境替换为新实例之前（大约 15 分钟）。

所以它将是某种自组织的、动态的环境。我正在考虑基于存储或表数据进行一些锁定。如果我们可以用微处理器术语来讨论的话，就有机会设置锁定超时和某种“看门狗”计时器。

4

1 回答 1

5

您寻求实现的目标有通用方法。

首先，您的主实例。您可以根据实例 ID 进行检查。这相当容易。您需要RoleEnvironment.CurrentRoleInstance来获取“当前实例”，现在将Id 属性与您从RoleEnvironment.CurrentRoleInstance.Role.Instances按 Id 排序的第一个成员中获得的属性进行比较。就像是：

var instance = RoleEnvironment.CurrentRoleInstance;
if(instance.Id.Equals(instance.Role.Instances.OrderBy(ins => ins.Id).First().Id))
{
 // you are in the single master
}

现在你需要在“治疗”/回收时选择主人。您需要获取 RoleEnvironment 的Changed事件。检查是否是TopologyChange（只检查是否是拓扑变化，不需要确切的拓扑变化）。如果是Topology Change - 根据上述算法选举下一个master。查看这篇关于如何准确执行事件挂钩和更改检测的精彩博客文章。

忘记加了。

如果您喜欢锁 - blob 租赁是获取/检查锁的最佳方式。但是，仅使用 RoleEnvironment 事件和基于实例 ID 的简单主选举，我认为您不需要那种复杂的锁定机制。此外 - 一切都在队列中，直到它被成功处理。因此，如果主人在处理某些事情之前死了，“下一个主人”将处理它。

于 2012-11-06T22:02:42.313 回答