我们希望让我们的客户能够每天，每周和每月安排重复性任务。线性可伸缩性对我们非常重要，这就是我们使用Windows Azure表存储而不是SQL Azure的原因。目前的设计如下： - 调度信息存储在表存储表中。例如：每天任务A;任务B，每周; ... - 有工作进程，每小时运行一次并查询此表。然后决定，他们必须运行给定的任务。
但是，如果多个工作者角色开始运行相同的任务呢？
其他一些要求： - 工作进程可以位于不同的时区。
Windows Azure Queue Storage可以解决上面提到的所有cuncurrency问题，但它也引入了一些新问题： - 我们应该生成多少个队列项？ - 如果客户更改重复率或撤消计划怎么办？
所以，我的问题是：如何使用Windows Azure存储设计具有多个异步工作者的定期任务调度程序？
答案 0 :(得分：3)
也许新的Azure Scheduler服务可以提供帮助？
答案 1 :(得分：1)
一些想法：
但是，如果多个工作者角色开始运行相同的任务呢？
这很可能会发生。为了避免这种情况，您可以做的是从表读取工作者角色实例（池中的任何工作者角色实例）并推送队列中的消息。虽然此实例正在执行此工作，但所有其他实例都在等待。要确定哪个实例可以正常工作，您可以使用blob租用功能。
其他一些要求： - 工作流程可能不同 时区。
不确定这一点。假设您正在谈论Cloud Services Worker Roles，他们可能位于不同的数据中心，但所有这些数据中心都位于UTC时区。
我们应该生成多少个队列项？
这实际上取决于需要完成多少工作。您可以将所有消息放入队列中。客户端一次最多只能从队列中出列32条消息。因此，如果你说100个任务，然后是100条消息，那么每个实例在一次调用队列服务时最多只能从队列中读取32条消息。
如果客户更改复发率或撤消复发率，该怎么办？ 调度？
这应该没问题，因为一旦任务完成，您必须从队列中删除该消息。下次调用任务时，您可以再次从表中读取，它将从表中为您提供有关该任务的最新信息。
答案 2 :(得分：0)
我会继续使用Azure表存储，但在工作人员开始处理之前将该进程标记为“进行中”。由于ATS支持由Etags控制的并发性，因此可以确保两个进程无法启动相同的进程
但是，我会考虑在作业意外失败并重新启动似乎已经过去的工作的过程时重试逻辑