Azure Webjob 计时器触发器不会触发 [英] Azure Webjob timer trigger does not fire

问题描述

我们有两个运行 TimerTrigger 的 Azure Webjob 部署(Prod 和 Test).两个网络应用程序都有单个实例.根据这篇文章，TimeTriggers 使用单例锁来确保没有并行调用.这两个实例使用相同的存储帐户.我们面临的问题是，只有一个部署似乎获得了锁，而其他部署无法获得锁.如果我们停止第一个 webjob，第二个获取锁并开始处理，反之亦然.

锁是否依赖于存储帐户?我们如何确保这两个部署具有单独的锁定机制并同时运行?

解决方案

你说得对，你必须使用不同的存储帐户.

来自文档:><块引用>

在幕后，TimerTrigger 使用 WebJobs SDK 的单例功能来确保在任何给定时间只有一个触发函数实例在运行.当 JobHost 启动时，对于您的每个 TimerTrigger 函数，都会占用一个 blob 租用(单例锁).这种分布式锁确保在任何时候都只有一个调度函数实例正在运行.如果该函数的 blob 当前未租用，则该函数将获取租用并立即开始按计划运行.如果无法获取到 blob 租用，则一般表示该函数的另一个实例正在运行，因此该函数未在当前主机中启动.发生这种情况时，主机将继续定期检查是否可以获得租用.这是作为一种恢复"模式完成的，以确保在稳定运行时，如果一个实例出现故障，另一个实例会注意到并从另一个实例停止的地方恢复.

如果您查看锁定机制的实现(StorageScheduleMonitor.cs):

• 作业获取容器内的锁(blob).
• blob 位于特定目录中(基于 HostId).
• blob 的名称不可配置.

所以基于@volodymyr-bilyachat 的回答，有两种可能:

• 拥有独立的存储帐户:如果每个环境(开发/暂存/生产)都有一个存储帐户，这是有意义的

• 指定 JobHostConfiguration 类的 HosId 属性:

  var config = new JobHostConfiguration();config.HostId = "dev|staging|prod";

We have two deployments (Prod and Test) of Azure Webjob running with TimerTrigger. Both the web apps have single instance. According to this article, TimeTriggers use singleton locks to make sure no parallel invocation. These two instances use the same storage accounts. The issue we are facing is that only one of the deployments seem to acquire the lock while other is unable to acquire the lock. If we stop the first webjob the second acquires lock and starts processing and vice-versa.

Does the lock depend on storage accounts? How can we make sure that both these deployments have separate locking mechanism and run at the same time?

解决方案

You're right, you have to use different storage accounts.

From the documentation:

Behind the scenes, TimerTrigger uses the Singleton feature of the WebJobs SDK to ensure that only a single instance of your triggered function is running at any given time. When the JobHost starts up, for each of your TimerTrigger functions a blob lease (the Singleton Lock) is taken. This distrubuted lock ensures that only a single instance of your scheduled function is running at any time. If the blob for that function is not currently leased, the function will acquire the lease and start running on schedule immediately. If the blob lease cannot be acquired, it generally means that another instance of that function is running, so the function is not started in the current host. When this happens, the host will continue to periodically check to see if it can acquire the lease. This is done as a sort of "recovery" mode to ensure that when running steady state, if an instance goes down, another instance notice and pick up where the other left off.

If you look at the implementation of the locking mecanism (StorageScheduleMonitor.cs):

• The job acquires a lock (blob) inside the container.
• The blob is located inside a particular directory (based on the HostId).
• the name of the blob is not configurable.

So based on @volodymyr-bilyachat answer, there are two possibilities:

• Having separated storage accounts: makes sense if you have a storage account per environment (dev/staging/prod)

• Specifying the HosId property of the JobHostConfiguration class:

  var config = new JobHostConfiguration();
  config.HostId = "dev|staging|prod";
  

这篇关于Azure Webjob 计时器触发器不会触发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！