azure-webjobs - 重新部署网站后，在连续 Azure WebJob 上运行的进程会发生什么情况？

Question

我读过关于优雅关机的文章 here使用 WEBJOBS_SHUTDOWN_FILE 和 here使用取消 token ，所以我理解正常关闭的前提，但是我不确定它们将如何影响正在处理队列消息的 WebJobs。

所以这是场景:

我有一个带有监听队列功能的 WebJob。

消息被添加到队列并且作业开始处理。

在处理过程中，有人插入开发，触发重新部署。

假设我已连接 WebJobs 以在 git push 上部署，此部署还将触发 WebJobs 更新，这(据我所知)将启 Action 业中的某种关闭工作流程。所以我有几个问题。

正在处理队列消息的作业是否会在作业退出之前完成对消息的处理？或者任何关闭通知本质上都被视为“这个婊子即将关闭。如果你没有任何东西来处理它，你就是SOL。”

如果我们是 SOL，那么我们处理关闭的最佳选择是否本质上是将您正在做的任何事情包装在相当于数据库事务中，并以所有更改在关闭时回滚的方式实现您的关闭处理程序？

如果队列消息正在处理中并且 WebJob 关闭，该消息会重新排队吗？如果没有，这是否意味着我的关闭处理程序需要处理重新排队该消息？

在 Job 被通知需要关闭后，监听队列的函数是否可以获取更多队列消息？

非常感谢这里的任何指导!此外，如果除了我提到的链接之外，还有其他关于如何处理工作停工的有用链接，如果您能分享这些链接，那就太好了。

Answer 1

经过不小的测试，我想我已经找到了我的问题的答案，我希望其他人可以从我的经验中获得一些见解。

注意:所有这些场景都使用 .NET 控制台应用程序和 Azure 队列进行了测试，因此我不确定 blob 或表存储或不同类型的作业文件类型将如何处理这些不同的场景。

将作业标记为退出后，正在运行的触发函数将在退出之前完成配置的时间量(宽限期)(默认为 5 秒，但我认为这是 configurable by using a settings.job file )。如果它们没有在宽限期内完成，该函数将退出。 Main()(或您在其中声明 host.RunAndBlock() 的任何文件)将在 host.RunAndBlock() 之后完成运行任何代码最长为宽限期剩余的时间(我不确定如果您使用无限循环而不是 RunAndBlock 会如何工作)。至于处理函数中的退出，您基本上可以“监听” CancellationToken，您可以将其传递给 IsCancellationRequired 的触发函数，然后相应地处理它。此外，如果您不自己处理退出，您就不是 SOL。哈扎!见第 3 点。

虽然如果您不处理退出，您就不是 SOL(请参阅第 3 点)，但我确实认为将您的所有工作包装在事务中是个好主意，除非您完全确定工作，否则您不会提交已经走到了尽头。这样，如果您的函数在进程中退出，您就不必担心数据损坏。我可以想到几个场景，您可能希望在事务通过时提交事务(例如批处理作业)，但是您需要构建数据或逻辑，以便在作业重新启动后不会重新处理先前处理的实体。

如果你不自己处理辞职，你就不会遇到麻烦。我对幕后发生的事情的理解几乎不存在，但我非常确定结果。如果一个函数正在处理队列消息并且在它完成之前被迫退出，不要害怕!当作业获取要处理的消息时，它实际上会将其隐藏在队列中一段时间​​。如果您的函数在处理消息时退出，则该消息将在 x 时间后再次“变得可见”，并且它将被重新抓取并针对刚刚部署的可能更新的代码运行。

所以我对#4 的发现有大约 90% 的信心。我这么说是因为尝试测试它涉及在窗口之间快速切换，而实际上并不完全确定某些部分发生了什么。但这是我发现的:如果在宽限期 b4 队列中添加了一条新消息，作业退出的可能性很小，我认为可能会发生以下两种情况之一:如果该函数在作业之前没有轮询该队列退出，则消息将保留在队列中，并在作业重新启动时被抓取。但是，如果函数确实获取了消息，它将被视为与任何其他被中断的消息相同:它将再次在队列中“变得可见”，并在重新启 Action 业时重新运行。

这几乎总结了它。我希望其他人会发现这很有用。如果您想要详细说明，请告诉我，我很乐意尝试。或者，如果我写得很满，而您有很多更正，那么这些可能更受欢迎!