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