我希望我的 Azure 角色为 reprocess data in case of sudden failures。我考虑以下选项。
对于要处理的每个数据块，我都有一个数据库表行，我可以添加一个表示“来自处理节点的最后一次 ping 的时间”的列。因此，当一个节点抓取一个数据块进行处理时，它会将“处理”状态和那个时间设置为“当前时间”，然后节点负责更新那个时间，比如每分钟更新一次。然后定期某个节点会询问“所有处理状态和 ping 时间大于 10 分钟的块”，并将这些块视为已废弃，并以某种方式将它们排队等待重新处理。
我有一个非常严重的担忧。上述方法要求节点具有或多或少相同的时间。我是否可以依靠所有 Azure 节点以某种合理的精度（比如几秒）具有相同的时间？
【问题讨论】：
标签： azure reliability fault-tolerance
对于 2 小时以下的处理时间，您通常可以依赖队列语义（可见性超时）。如果您将数据存储在 blob 存储中，则可以让工作人员弹出包含要处理的 blob 名称的队列消息，并在消息上设置合理的可见性超时（今天最多 2 小时）。一旦完成工作，它就可以删除队列消息。如果失败，则永远不会调用删除，并且在可见性超时后，它将重新出现在队列中以进行重新处理。这就是为什么你希望你的工作是幂等的，顺便说一句。
对于持续时间超过两个小时的处理，我通常推荐一种租赁策略，其中工作人员使用 Windows Azure blob 存储中的内在租赁功能租赁基础 blob 数据（如果可能，或者虚拟 blob）。当工作人员去检索文件时，它会尝试租用它。已租用的文件表示当前正在处理它的工作人员角色。如果发生故障，租约将被打破，它会被另一个实例租用。租约必须每分钟左右更新一次，但可以无限期地持有。
当然，您将要处理的数据保存在 blob 存储中，对吗？ :)
如前所述，您不应依赖 VM 节点之间的同步时间。如果您出于任何原因存储日期时间 - 请使用 UTC，否则您会后悔的。
【讨论】：
这里的答案是不使用基于时间的同步（但是，如果您愿意，请确保使用 UTCNow），但仍然无法保证任何地方的时钟都已同步。也不应该有。
对于您描述的问题，基于队列的系统就是答案。我已经引用了很多，并且会再做一次，但是我已经解释了基于队列的系统in my blog post 的一些好处。
思路如下：
通过您的方法，我将使用 AppFabric 队列，因为您还可以拥有主题和订阅，从而可以监控数据项。我的博客文章中的示例涵盖了这个确切的场景，唯一的区别是我没有使用工作者角色，而是从我的 Web 应用程序中轮询队列。但概念是一样的。
【讨论】：
我会尝试使用队列存储的不同方式。如果您在超时的情况下将数据块弹出队列，那么让您的处理节点（工作角色？）将该数据从队列中拉出。
数据从队列中弹出后，如果处理节点没有从队列中删除该条目，它将在超时时间后重新出现在队列中进行处理。
【讨论】：
远程桌面进入角色实例并检查 (a) 时区（我认为是 UTC），以及 (b) 在日期和时间设置中启用了 Internet 时间。如果是这样，那么您可以相信它们之间的距离不超过几毫秒。 （这并不是说使用消息队列的建议不起作用，但也许它们不适合您的需求。）
【讨论】：