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