防止 Azure 在处理时停止工作线程
这可能是一个简单的问题，但我还没有看到直接的答案。假设我正在使用 Azure 辅助角色来执行某种长时间运行的任务，例如需要一个小时的任务。现在假设 MS 决定工作角色需要对其进行一些维护，并尝试在工作 30 分钟后将其关闭。
有没有办法让 Azure 等到该角色运行完成后再进行维护？我确实看到了 OnStop 方法，但似乎您只能在关闭之前让事情延迟一段设定的时间。
如果这是不可能的，那么对于需要相当长的时间且无法分成更小的块的操作，您如何计划呢？您是否会回滚之前所做的任何更改，然后重试该任务？
This may be kind of a simple question, but I haven't seen a direct answer yet. Say I'm using an Azure worker role to do some sort of long running task, say one that takes an hour. Now say MS decides that worker role needs some maintenance done on it and tries to shut it down 30 minutes into the work.
Is there a way to make Azure wait until that role finishes running to do maintenance? I do see the OnStop method, but it seems like you can only make things delay for a set amount of time before you get shut down anyway.
If this isn't possible, how do you plan around this for operations that take a decent amount of time and can't be split up into smaller chunks? Would you just rollback any changes made earlier and then retry the task?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以处理 Stopping 事件来延迟实例关闭（在正常关闭模式下）。在崩溃情况下，您无法真正阻止关闭...
这是缓解措施的建议。假设您的任务是队列驱动的。让我们假设您的消息类似于
PROCESSWIDGET|123。您在工作实例中读取队列消息并开始处理。您实际上可以一路修改队列消息，并记录您的进度。因此，在这个虚构的示例中，假设有 4 个步骤来完成长达一小时的任务，每个步骤需要 15 分钟。每个步骤完成后，您可以更新消息，附加检查点状态。完成第一个任务后，您立即更新消息，现在它看起来类似于
PROCESSWIDGET|123|STEP2。现在...出了问题，虚拟机实例由于某种原因终止了。队列消息最终再次变得可见，另一个工作实例读取它，并看到附加了下一步要执行的消息。假设您已将中间文件存储在 Blob 存储（或其他一些持久存储）中，您可以从上次中断的位置继续，而不是从头开始重新处理。
有关详细信息，请参阅此 MSDN 页面
UpdateMessage()方法。You can handle the Stopping event to delay instance shutdown (in the graceful shutdown mode). In a crash situation, you can't really prevent shutdown...
Here's a suggestion for mitigation. Let's say your task is queue-driven. Let's pretend your message looks something like
PROCESSWIDGET|123.You read the queue message in a worker instance and start processing. You can actually modify the queue message along the way, and record your progress. So, in this fictitious example, let's say there are 4 steps to complete the hour-long task, each taking 15 minutes. As each step completes, you can update your message, appending a checkpoint status. Right after completing the first task, you update the message, and now it looks something like
PROCESSWIDGET|123|STEP2.Now... something goes wrong and the VM instance dies for some reason. The queue message eventually becomes visible again, another worker instance reads it, and sees the message appended with the next step to perform. Assuming you've stored intermediate files in Blob storage (or some other persistent storage), you can pick up where you left off, and not re-process from the beginning.
See this MSDN page for details of the
UpdateMessage()method.