如何自动启动 Azure 队列?

发布于 2024-08-08 10:03:13 字数 322 浏览 8 评论 0原文

我想构建一个具有两个辅助角色且没有 Web 角色的 Azure 应用程序。当辅助角色第一次启动时,我只希望其中一个角色一次性执行以下操作:

  • 下载并解析主文件,然后根据主文件将多个“子”任务排入队列 主文件的内容
  • 将单个主文件下载“子”任务排入队列以在第二天运行

每个“子”任务将由两个工作人员完成,直到任务队列耗尽。将整个事情视为“启动泵”

如果我通过调用 Web 角色将第一个“主”任务手动添加到队列中,这种事情真的很容易,但在自动启动中似乎很难做到模式。

任何在这方面的帮助将不胜感激!

谢谢.....

I want to build an Azure application that has two worker roles and NO web roles. When the worker roles first start up I want ONLY ONE of the roles to do the following a single time:

  • Download and parse a master file then enqueue multiple "child" tasks based on the
    contents of the master file
  • Enqueue a single master file download "child" task to run the next day

Each of the "child" tasks would then be done by both of the workers until the task queue was exhausted. Think of the whole things as "priming the pump"

This sort of thing is really easy if I add the the first "master" task manually in a queue by calling a web role but seems to be really hard to do in an auto-start mode.

Any help in this regard would be greatly appreciated!

Thanks.....

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

南街九尾狐 2024-08-15 10:03:13

一种可能性:不调用 Web 角色,而是直接加载队列。 (听起来这是一种您希望自动启动以完成某些工作然后再次关闭的应用程序......如果您要实现自动化,那么自动加载队列应该很简单。

) (也许)更好的选择:使用某种锁定机制来确保只有一个工作实例执行初始化工作。执行此操作的一种方法是尝试创建队列(或 blob,或表中的实体)。如果它已经存在,则另一个实例正在处理初始化。如果创建成功,那么这就是该实例的工作。

请注意,使用租约总是比使用锁更好,以防执行初始化的实例失败。考虑使用超时(例如,将时间戳存储在表存储中、blob 的元数据中或队列的名称中......)。

One possibility: instead of calling a web role, just load the queue directly. (It sounds like this is the sort of application you'll want to automatically spin up to do some work and then shut down again... if you're automating that, it should be trivial to also automate loading the queue.)

A (perhaps) better option: Use some sort of locking mechanism to make sure only one worker instance does the initialization work. One way to do this is to try to create the queue (or a blob, or an entity in a table). If it already exists, then the other instance is handling initialization. If the create succeeds, then it's this instance's job.

Note that it's always better to use a lease than a lock, in case the instance that's doing the initialization fails. Consider using a timeout (e.g. storing a timestamp in table storage or in the metadata of the blob or in the name of the queue...).

红ご颜醉 2024-08-15 10:03:13

我们最终遇到了完全相同的问题,这就是为什么我们引入了 O/C映射器(对象到云)。基本上,您需要引入两种类型的云服务:

  1. QueueService,它在可用时使用消息。
  2. ScheduledService 按计划触发操作。

然后,正如其他人所建议的,在云中,您确实更喜欢使用租用而不是锁定,以避免您的云应用程序由于临时硬件(或基础设施)问题而最终永远冻结。

We did end-up with the exact same sort of problem, that's why we introduced a O/C mapper (object to cloud). Basically, you want to introduce two types of cloud services:

  1. QueueService that consumes messages whenever available.
  2. ScheduledService that triggers operations on a scheduled basis.

Then, as others suggested, in the cloud, you really prefer using leases instead of locks, in order to avoid your cloud app to end up freezed forever due to a temporary hardware (or infrastructure) issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文