同一服务总线队列消息多次运行的Azure函数 [英] Azure function running multiple times for the same service bus queue message

查看:111
本文介绍了同一服务总线队列消息多次运行的Azure函数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个Azure函数(基于新的C#函数而不是旧的.csx函数),每当一条消息进入Azure Service Bus队列时,就会触发该函数.触发功能后,它将开始处理服务总线消息.它对消息进行解码,读取一堆数据库,更新一堆其他数据库等,有时可能需要30分钟以上的时间.

I have an Azure function (based on the new C# functions instead of the old .csx functions) that is triggered whenever a message comes into an Azure Service Bus Queue. Once the function is triggered, it starts processing the service bus message. It decodes the message, reads a bunch of databases, updates a bunch of others, etc... This can take upwards of 30 minutes at times.

因为这不是时间敏感的过程,所以30分钟甚至60分钟都不是问题.问题在于,与此同时,Azure Function似乎再次启动,并一次又一次接收相同的消息并对其进行重新处理.这是一个问题,并且会导致我们的业务逻辑出现问题.

Since, this is not a time sensitive process, 30 minutes or even 60 minutes is not an issue. The problem is that in the meanwhile, Azure Function seems to kick in again and picks up the same message again and again and reprocesses it. This is an issue and cause problems in our business logic.

因此,问题是,我们是否可以强制Azure函数以单例模式运行?或者,如果不可能,我们如何更改轮询间隔?

So, the question is, can we force the Azure function to run in a singleton mode? Or if that's not possible, how do we change the polling interval?

推荐答案

AutoRenewTimeout并不如建议的那么好.您需要注意它的缺点.这是无法保证的操作.作为客户端发起的操作,它可能并且有时失败,使您的状态保持在今天的状态.

AutoRenewTimeout is not as great as suggested. It has a downside that you need to be aware of. It's not a guaranteed operation. Being a client side initiated operation, it can and sometimes will fail, leaving you in the same state as you are today.

您可以解决的问题是审查您的设计.如果您的进程运行时间很长,那么您将处理该消息,然后将处理移交给可以运行时间超过MaxLockDuration的进程.您的函数花了很长时间这一事实表明您的运行过程很漫长.消息不是为此目的而设计的.

What you could do to address it is to review your design. If you have a long running process, then you process the message, and hand off processing to something that can run longer than MaxLockDuration. The fact that your function is taking so long, indicates you have a long running process. Messaging is not designed for that.

一种可能的解决方案是获取一条消息,在存储表中注册处理意图.具有另一个存储表触发功能以启动处理,该过程可能需要X分钟.将其标记为单例.这样,您将并行处理消息,将对长时间运行的处理的请求"写入存储表,完成Service Bus消息传递,因此不会触发消息的重新处理.通过长时间运行的处理,您可以决定如何处理故障案例.

One of the potential solutions would be to get a message, register processing intent in a storage table. Have another storage table triggered function to kick-off processing that could take X minutes. Mark it as a singleton. By doing so, you'll be processing your messages in parallel, writing "request for long running processing" into storage table, completing Service Bus messaging and therefore not triggering their re-processing. With the long running processing you can decide how to handle failure cases.

希望有帮助.

这篇关于同一服务总线队列消息多次运行的Azure函数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆