我可以对Azure上的全球时间做哪些假设？

我希望我的Azure角色能够成功。我考虑以下选项：

对于要处理的每个数据块，我都有一个数据库表行，我可以添加一列，表示“处理节点最后一次ping的时间”。因此，当一个节点抓取一个数据块进行处理时，它会将“处理”状态和该时间设置为“当前时间”，然后由节点负责更新该时间，比如每一分钟更新一次。然后，周期性地，一些节点将请求“所有具有处理状态和ping时间大于十分钟的块”，并将这些块视为放弃并以某种方式将它们排队进行再处理。

---

我有一个非常严重的问题。上述方法要求节点的时间或多或少相同。我能依靠所有Azure节点以合理的精度（比如几秒钟）拥有相同的时间吗？

我会使用队列存储以不同的方式尝试这一点。如果在队列中弹出数据块并超时，则让处理节点（工作人员角色？）将此数据从队列中拉出

---

数据从队列中弹出后，如果处理节点没有从队列中删除条目，它将在超时后重新出现在队列中进行处理。

我将尝试使用队列存储的另一种方法。如果在队列中弹出数据块并超时，则让处理节点（工作人员角色？）将此数据从队列中拉出

---

数据从队列弹出后，如果处理节点没有从队列中删除条目，它将在超时后重新出现在队列中进行处理。

这里的答案不是使用基于时间的同步（如果您愿意，请确保使用UTCNow），但是仍然不能保证时钟是同步的。也不应该有

对于您所描述的问题，基于队列的系统就是答案。我已经参考了很多关于它的内容，并且还会再做一次，但是我已经解释了基于队列的系统的一些好处

其思路如下：

您将工作项放入队列

您的工作人员角色（其中一个或多个）查看并锁定消息

您尝试处理该消息，如果成功，则从队列中删除该消息

如果没有，你就让它呆在原地

---

对于您的方法，我将使用AppFabric队列，因为您还可以拥有主题和订阅，这允许您监视数据项。我的博客文章中的示例涵盖了这个确切的场景，唯一的区别是，我从web应用程序轮询队列，而不是使用工作者角色。但是概念是一样的。

这里的答案不是使用基于时间的同步（如果您愿意，请确保使用UTCNow），但是仍然不能保证时钟在任何地方同步。也不应该有

对于您所描述的问题，基于队列的系统就是答案。我已经参考了很多关于它的内容，并且还会再做一次，但是我已经解释了基于队列的系统的一些好处

其思路如下：

您将工作项放入队列

您的工作人员角色（其中一个或多个）查看并锁定消息

您尝试处理该消息，如果成功，则从队列中删除该消息

如果没有，你就让它呆在原地

---

对于您的方法，我将使用AppFabric队列，因为您还可以拥有主题和订阅，这允许您监视数据项。我的博客文章中的示例涵盖了这个确切的场景，唯一的区别是，我从web应用程序轮询队列，而不是使用工作者角色。但概念是相同的。

对于2小时以下的处理时间，您通常可以依赖队列语义（可见性超时）。如果数据存储在blob存储器中，则可以让工作人员弹出包含要处理的blob名称的队列消息，并在消息上设置合理的可见性超时（今天最多2小时）。一旦完成工作，它就可以删除队列消息。如果失败，则永远不会调用delete，并且在可见性超时后，它将重新出现在队列上以进行重新处理。这就是为什么你希望你的工作是幂等的，顺便说一句

对于持续时间超过两小时的处理，我通常建议采用租用策略，工作人员使用Windows Azure blob存储中的intrisic租用功能租用基础blob数据（如果可能或虚拟blob）。当一个工人去检索一个文件时，他会试图租用它。已租用的文件表示当前正在处理该文件的工作人员角色。如果发生故障，租约将被打破，并将被另一个实例出租。租约必须每分钟左右续签一次，但可以无限期持有

当然，您将要处理的数据保存在blob存储中，对吗？：）

---

如前所述，您不应该依赖于VM节点之间的同步时间。如果出于任何原因存储日期时间-请使用UTC，否则您以后会后悔。

对于2小时以下的处理时间，您通常可以依赖队列语义（可见性超时）。如果数据存储在blob存储器中，则可以让工作人员弹出包含要处理的blob名称的队列消息，并在消息上设置合理的可见性超时（今天最多2小时）。一旦完成工作，它就可以删除队列消息。如果失败，则永远不会调用delete，并且在可见性超时后，它将重新出现在队列上以进行重新处理。这就是为什么你希望你的工作是幂等的，顺便说一句

对于持续时间超过两小时的处理，我通常建议采用租用策略，工作人员使用Windows Azure blob存储中的intrisic租用功能租用基础blob数据（如果可能或虚拟blob）。当一个工人去检索一个文件时，他会试图租用它。已租用的文件是ind