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

Question

我希望我的Azure角色为reprocess data in case of sudden failures。我考虑以下选项。

对于要处理的每个数据块，我有一个数据库表行，我可以添加一个列，意思是“从处理节点上次ping的时间”。因此，当节点抓取数据块进行处理时，它将“处理”状态和该时间设置为“当前时间”，然后节点负责更新该时间，例如每隔一分钟。然后定期某个节点将询问“所有具有处理状态和ping时间大于10分钟的块”，并将这些块视为已放弃，并以某种方式将它们排队以进行重新处理。

我有一个非常严重的担忧。上述方法要求节点或多或少具有相同的时间。我可以依赖具有相同时间且具有一定合理精度的所有Azure节点（比如几秒钟）吗？

Answer 1

这里的答案不是使用基于时间的同步（但是，如果你要确保使用UTCNow），但仍无法保证时钟同步的任何地方。也不应该有。

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

这个想法如下：

1. 您将工作项放入队列
2. 你的工人角色（其中一个或多个）偷看＆amp;锁定消息
3. 您尝试处理邮件，如果成功，则从队列中删除邮件
4. 如果没有，你让它留在原地

根据您的方法，我会使用AppFabric Queues，因为您也可以使用主题＆amp;订阅，允许您监视数据项。我的博客文章中的示例涵盖了这个确切的场景，唯一的区别是我没有工作者角色，而是从我的Web应用程序中轮询队列。但这个概念是一样的。

Answer 2

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

对于持续时间超过两小时的处理，我通常建议使用租赁策略，其中工作人员使用Windows Azure blob存储中的内部租用功能租用底层blob数据（如果可能，或者使用虚拟blob）。当工作人员去检索文件时，它会尝试租用它。已租用的文件表示当前正在处理它的工作人员角色。如果发生故障，租约将被破坏，另一个实例将变为可租赁。租约必须每隔一分钟更新一次，但可以无限期地保留。

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

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

Answer 3

我会尝试使用队列存储的不同方式。如果您在超时的队列中弹出数据块，那么让您的处理节点（工作者角色？）将这些数据从队列中拉出来。

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

Answer 4

远程桌面到角色实例并检查（a）时区（UTC，我认为），以及（b）在日期和时间设置中启用Internet时间。如果是这样，那么你可以依赖它们不超过几毫秒。 （这并不是说使用消息队列的建议不起作用，但可能它们不适合您的需要。）