我们有几个 .NET Core Azure 隔离函数：
其中一个由每 30 秒计时一次的计时器触发。它检查是否有新内容，如果有，则将新消息发送到队列。另一种是使用前面提到的队列的队列触发器。
队列触发器运行的代码还会更新一个表以跟踪它正在处理此新内容，从而防止计时器函数为相同内容添加新消息。
最近经常出现这样的情况：计时器运行并向队列添加一条消息，但队列触发器直到 30 秒后将重复消息添加到队列时才触发，此时两条消息都会触发队列功能。这会导致它们由于并发操作而失败。就在最近，在触发器同时触发所有三个消息之前，它达到了三个重复消息。
我们将对代码进行更改，以更好地应对这种可能性；然而，这个设置已经在几个项目中运行了几年，我们以前从未遇到过这个问题。
将消息发送到队列时没有提供超时可见性（我认为这意味着它默认为 0 超时）。
该应用程序位于美国东部，队列的存储帐户的主要位置是美国东部，次要位置是美国西部，因此如果使用次要位置，可能会偶尔出现延迟问题？但这并不能解释为什么当添加第二个（或第三个）时它会立即触发。这是一个间歇性问题，因此不确定是否存在由于 Azure 资源的共享性质而导致的任何延迟？
预期的行为是计时器函数向队列添加一条消息，并且队列触发器在合理的延迟（几秒钟）内触发，但最好是“立即”。如果计时器函数仍在处理，则正在处理的消息将阻止在 30 秒后再次运行时添加另一条消息。
再次，将实施一些代码更改来处理潜在的重复消息，我们需要解决的问题是为什么队列消息有时会延迟 30-60 秒（或直到另一条消息添加到队列中）。
Azure 资源的设置没有任何变化，这表明队列消息的处理会减少。
这样说真的很难。它确实可能与 Azure 基础设施、配置或特定托管环境有关。但您还说您正在使用弹性高级计划，因此与消费计划相比，“冷启动”效应应该最小化。
不确定您的负载是什么，但Elastic Premium功能至少使一个实例保持温暖，但如果存在高负载或间歇性负载，Azure可能仍需要分配额外的资源或“唤醒”实例，从而导致延迟。
我可以建议进行一些检查-
MessageCountLatency由于您的函数有时会因延迟而处理重复消息，因此在代码中实施重复数据删除策略可以防止重复处理。看看这个参考线程是否有帮助。