检测Azure实例的崩溃

我想检测到我的Azure角色的实例崩溃的事实。在我的情况下检测意味着我的角色的另一个实例被通知有关崩溃。请查看下面解释的我的想法或提出其他解决方案。检测Azure实例的崩溃

我想到的想法利用了Azure队列中的项目处理时间有限的事实。

配置一个天青队列。角色的所有实例都监听该队列。
配置角色实例有内部端点
当实例的启动时，它发布消息队列。该消息包含实例A的ID，A的内部端点的IP，该消息应该被转发回A的标记。
最有可能的消息在另一个实例B上结束.B将把消息Id和PopReceipt转发给通过内部端点。实例A使用此ctr http://msdn.microsoft.com/en-us/library/dn451949.aspx创建CloudQueueMessage的对象。
实例A开始无限更新接收消息的可见性超时。从Azure Queue的角度来看，此消息将会被处理很长时间。在第一次更新A中删除“转发此消息”标记。
如果实例A崩溃，停止延长处理时间。该消息很快会自动显示给其他实例。
实例C接收消息并了解崩溃的消息A：消息包含实例A的ID并且没有“forward-this-message”标记。
如果实例A正常停止，它会将其队列消息标记为已处理。

来源

2013-10-22 SergeyS

实例A无法更新步骤＃5中的可见性超时会发生什么情况？ –

实例A应该开始提前更新可见性超时，以便有可能重试的时间。这将缓解瞬态问题。如果拼命无法更新它可能会自杀 - 请Azure回收该实例。 – SergeyS

您可以公开和私人端点在这些实例上进行外部ping？ – Igorek

这一切似乎很令人费解。

就个人而言，我会回去看原来假设我需要知道什么时候一个实例崩溃 - 并考虑我做什么用的信息。我倾向于乐观的解决方案（即假设成功和处理失败）而不是悲观的解决方案（即假设失败，因此提供某种机制以确保成功）。后者的一个问题是，你将不得不处理未声明的实例崩溃 - 所以为什么不把它作为默认行为。这将调用实例上的操作 - 并处理发生的任何故障。

例如，如果我想对另一个实例我会负载均衡对所有其他实例，并在检测到故障实例内部端点调用操作，尽量在另一个实例上运行。瑞恩邓恩有什么现在是一个古老的post，其中包括对内部端点的负载平衡。

我的基本观点是，这将是很难与消息传递从一个实例到另一个有力执行这种类型的业务流程。有太多可能的失败点。提出更直接解决潜在需求的解决方案会更好。简单的解决方案几乎总是比更复杂的解决方案更可取。

来源

2013-10-22 19:39:19

我想确保可靠的工作流执行：一旦实例接受，工作流必须完成，而不管实例可能崩溃。实现这一点的一种方式是为每个工作流程提供Azure队列消息。这是一个经典的解决方案。但速度慢，成本高。我可以通过跟踪实例而不是单个工作流来减少队列中的消息数量。 – SergeyS

当实例C获知崩溃的A时，它将查询数据库以获取实例A正在处理的工作流的列表。实例C通过更新数据库记录从A接管各项工作。当所有工作都被C标记为“已坠毁”的信息被接收为“完成”时。如果实例C依次崩溃 - “已崩溃”消息将自动返回到队列中，并将被另一个实例拾取。 – SergeyS

队列服务每秒最多可处理2000条消息，因此除非这些工作流程是亚秒级的，否则我不会明白为什么它们会影响行为 - 特别是考虑到不使用队列的悲伤可能会导致这种情况。您是否考虑过在每个工作流程中使用单个消息并通过更新消息来跟踪可隔离的消息状态？例如，工作流程可能包含3个步骤 - 您只需在每个步骤完成时更新消息。有了队列，你当然必须处理幂等性。 –

检测Azure实例的崩溃

回答

相关问题