用于非事务集成任务的Azure Worker角色的多个实例

时间:2014-02-07 08:59:49

标签: azure architecture transactions azure-worker-roles idempotent

我们有一个即将开展的项目,我们需要通过各种传输与第三方集成以从中获取数据。

像WCF Endpoints& Web API Rest端点很好。

然而,在2个场景中,我们需要从pop3帐户中选择包含xml的自动生成的电子邮件,或者从外部SFTP帐户中提取xml文件。

我即将开始对这些进行原型设计,但我想知道在多实例工作者角色环境中是否存在关于如何处理这些非事务性系统的任何标准实践,模式或指南。即。

如果2名工作人员同时连接到弹出帐户或同时连接到同一FTP,会发生什么情况。

如果1名工作人员从FTP删除该文件而另一名工作人员处于中期下载状态,会发生什么情况。

控制复制应该不是问题,因为我们将应用程序端的所有内容记录到数据库中,并且所有内容都应该是唯一可识别的,因此我们将能够添加if-not-exists-create-else-跳过工人的逻辑,但我只是想知道还有什么我应该考虑使其更具弹性/幂等。

2 个答案:

答案 0 :(得分:1)

查看最近发布的Cloud Design Patterns。您可能能够找到所需的相应模式和示例代码。

答案 1 :(得分:1)

只是大声思考,因为数据主要是文件和电子邮件,你可以做的一件事是,而不是通过你的工作角色直接处理它们,你要做的第一件事是将它们保存在blob存储中。因此会有一些工作者角色实例会定期轮询POP3服务器/ SFTP站点并从那里提取数据并将其推送到blob存储中。写入blob时,同一实例也可以从源中删除数据。使用这种方法,您不必担心重复记录,因为blob将被覆盖(假设每个消息/文件都有唯一的标识符,并且blob的名称是该标识符)。

一旦文件位于blob存储中,您就可以在Windows Azure Queue中编写一条消息,其中包含有关此blob的详细信息(可能是blob URL等)。然后使用Windows Azure队列的“获取”语义,您的工作者角色实例开始获取和处理这些消息。由于Get语义,一旦从队列中获取消息,它就会对其他调用者(在这种情况下为工作者角色实例)不可见。这样您就可以处理重复的消息处理。

<强>更新

So I'm trying to combat against two competing instances pulling the same file at the same moment from the SFTP

为此,我会推销我最喜欢的Master/Slave Concept :)。基本上,这个想法是每个实例都会尝试在单个blob上获得租约。获得租约的实例成为主人,其他人则成为奴隶。 Master将从SFTP获取数据,而slave将等待。我在我的博客文章中描述了这个概念,您可以在这里阅读:http://gauravmantri.com/2013/01/23/building-a-simple-task-scheduler-in-windows-azure/,尽管博客的上下文有些不同。