0

我希望我的 Azure 角色在发生突然故障时重新处理数据。我考虑以下选项。

对于要处理的每个数据块，我都有一个数据库表行，我可以添加一个表示“来自处理节点的最后一次 ping 的时间”的列。因此，当一个节点抓取一个数据块进行处理时，它会将“处理”状态和那个时间设置为“当前时间”，然后节点负责更新那个时间，比如每分钟更新一次。然后定期某个节点会询问“所有处理状态和 ping 时间大于 10 分钟的块”，并认为这些块已被废弃，并以某种方式将它们排队等待重新处理。

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

4

4 回答 4

2

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

对于您描述的基于队列的系统的问题，答案就是答案。我已经引用了很多，并且会再做一次，但是我已经在我的博客文章中解释了基于队列的系统的一些好处。

思路如下：

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

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

于 2011-07-19T10:28:44.153 回答
2

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

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

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

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

于 2011-07-19T15:39:59.940 回答
1

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

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

于 2011-07-19T08:50:44.353 回答
1

远程桌面进入角色实例并检查（a）时区（我认为是UTC），以及（b）在日期和时间设置中启用了互联网时间。如果是这样，那么您可以相信它们之间的距离不超过几毫秒。（这并不是说使用消息队列的建议不起作用，但也许它们不适合您的需求。）

于 2011-07-20T01:27:52.037 回答