我可以对Azure上全球时间什么假设？ [英] What assumptions can I make about global time on Azure?

问题描述

我希望我的Azure角色来重新处理数据的情况下，突然故障的。我认为下面的选项。

I want my Azure role to reprocess data in case of sudden failures. I consider the following option.

有关数据的每个块来处理我有一个数据库表行，我可以添加一列意为从一个处理节点最后平的时间。所以，当一个节点抓了一个数据块来处理这台处理状态，那个时候当前时间，然后它的节点负责更新那个时候说每隔一分钟。然后定期一些节点会问有处理状态和ping时间十多分钟以上所有块，并考虑这些块已被放弃，并在某种程度上他们排队进行加工处理。

For every block of data to process I have a database table row and I could add a column meaning "time of last ping from a processing node". So when a node grabs a data block for processing it sets "processing" state and that time to "current time" and then it's the node responsibility to update that time say every one minute. Then periodically some node will ask for "all blocks that have processing state and ping time larger than ten minutes" and consider those blocks as abandoned and somehow queue them for reprocessing.

我有一个很严重的问题。上述方法要求节点具有更多或更少的同一时间。我可以依靠具有相同时间与一些合理的precision Azure的所有节点上（比如几秒钟）？

I have one very serious concern. The above approach requires that nodes have more or less the same time. Can I rely on all Azure nodes having the same time with some reasonable precision (say several seconds)?

推荐答案

有关处理时间小于2小时，你通常可以依靠队列语义（可见性超时）。如果您有存储在Blob存储中的数据，你可以有一个工人弹出包含blob的名字上工作，并设置一个合理的可见性超时的消息（最多2个小时今天）队列中的消息。一旦它完成的工作，它可以删除队列消息。如果失败，则删除不会被调用和可见性超时后，会重新出现在队列中进行再加工。这就是为什么你想你的工作幂等，顺便说一句。

For processing times under 2 hrs, you can usually rely on queue semantics (visibility timeout). If you have the data stored in blob storage, you can have a worker pop a queue message containing the name of the blob to work on and set a reasonable visibility timeout on the message (up to 2 hrs today). Once it completes the work, it can delete the queue message. If it fails, the delete is never called and after the visibility timeout, it will reappear on the queue for reprocessing. This is why you want your work to be idempotent, btw.

对于两个小时持续时间更长的处理，我一般建议租赁策略，其中职工租赁的底层BLOB数据（如果可能还是一个虚拟的blob其他）使用的Windows Azure Blob存储的intrisic租赁功能。当一个工人去检索文件，它会尝试租用它。一个已经出租的文件表明目前处理它辅助角色。如果发生故障，租赁将被打破，这将在另一个实例成为可出租。租赁必须更新每分钟左右，但它们可以无限期持有。

For processing that lasts longer than two hours, I generally recommend a leasing strategy where the worker leases the underlying blob data (if possible or a dummy blob otherwise) using the intrisic lease functionality in Windows Azure blob storage. When a worker goes to retrieve a file, it tries to lease it. A file that is already leased is indicative of a worker role currently processing it. If failure occurs, the lease will be broken and it will become leasable by another instance. Leases must be renewed every min or so, but they can be held indefinitely.

当然，要保持在Blob存储要处理的数据，对不对？ ：）

Of course, you are keeping the data to be processed in blob storage, right? :)

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

As already indicated, you should not rely on synchronized times between VM nodes. If you store datetimes for any reason - use UTC or you will be sorry later.

这篇关于我可以对Azure上全球时间什么假设？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！