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

问题描述

我们有两个使用TimerTrigger运行的Azure Webjob部署(产品和测试).这两个Web应用程序都具有单个实例.根据本文，TimeTriggers使用单例锁来确保没有并行调用.这两个实例使用相同的存储帐户.我们面临的问题是，只有一个部署似乎获得了锁定，而其他部署却无法获得该锁定.如果我们停止第一个Web作业，第二个Web作业将获得锁定并开始处理，反之亦然.

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.

来自文档:

在后台， TimerTrigger 使用WebJobs SDK的 Singleton 功能来确保在给定的时间仅运行触发函数的单个实例. JobHost启动时，对于您的每个TimerTrigger功能，都会获取一个Blob租约(Singleton Lock).这种分布的锁可确保在任何时候仅运行计划功能的单个实例.如果当前未租用该函数的Blob，则该函数将获取租约并立即按计划开始运行. 如果无法获取Blob租约，通常意味着该功能的另一个实例正在运行，因此该功能不在当前主机中启动.发生这种情况时，主机将继续定期检查以查看其是否可以获取租约.这是一种恢复"模式，以确保在稳定状态下运行时，如果一个实例发生故障，另一个实例会通知并在另一个实例停止的地方继续工作.

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):

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

因此，根据@ volodymyr-bilyachat答案，有两种可能性:

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

• 具有单独的存储帐户:如果您在每个环境(dev/staging/prod)中都有一个存储帐户，则很有意义

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

指定JobHostConfiguration类的HosId属性:

Specifying the HosId property of the JobHostConfiguration class:

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

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