azure 服务总线的 Azure Function App 延迟重试

问题描述

首先让我解释一下我有什么.我自己有一个带有 Azure Function App 的 Azure 服务总线.服务总线设置为使用 SQL 过滤器将特定消息类型推送到特定主题.然后使用我的 Azure Function App 这些将获取最新消息然后处理它.

First let me explain what I have. I have myself an Azure Service Bus with an Azure Function App. The Service Bus is setup to use SQL Filters to push specific message types into specific topics. Then using my Azure Function App these will get the newest message and then process it.

一个基本的例子

1:我向我的 EmailAPI 发送请求

1: I send a request to my EmailAPI

2:EmailAPI 然后将一条新消息推送到具有电子邮件"类型的服务总线

2: EmailAPI then pushing a new message into the Service Bus with a type of "Email"

3:SQL 过滤器然后看到类型是电子邮件"，并被放置在 Service Bux 中的电子邮件主题中

3: The SQL Filter then sees the type is of "Email" and is placed into the email Topic in the Service Bux

4:EmailListener Azure Function 监控服务总线并通知新消息

4: The EmailListener Azure Function monitors the Service bus and notices a new message

5:收集服务总线消息并处理它(基本上只是使用提供的信息发送电子邮件)

5: Gather the Service Bus message and process it (basically just send the email using the information provided)

现在假设由于某种原因 SMTP 服务器连接有点中断，有时我们在尝试发送电子邮件 (EmailListener) 时收到 TimeOutException.现在当抛出异常时会发生什么，Function App EmailListener 将立即尝试再次发送它，无需等待，它只会尝试再次发送它.它将总共执行 10 次，然后通知 Service Bus 将消息放入死信队列.

Now let's say for some reason the SMTP server connection is a little broken and some times we get a TimeOutException when attempting to send the email (EmailListener). What happens now when an exception is thrown, the Function App EmailListener will attempt to send it again instantly, no wait, it will just attempt to send it again. It will do this for a total of 10 times and then inform the Service Bus to place the message in the Dead Letter queue.

我正在尝试做的是，当抛出异常(例如 TimeOutException)时，我们会等待 X 时间，然后再尝试再次处理相同的消息.我查看了许多不同的帖子，讨论了 host.json 并尝试设置这些设置，但这些都没有奏效.我找到了一个解决方案，但是该解决方案要求您创建消息的克隆并将其推回服务总线并延迟处理时间.如果 Azure Service Bus/Function App 可以自行处理重试，我不希望实现自己的手动延迟系统.

What I am attempting to do is when an exception is thrown (such as TimeOutException), we wait X amount of time before attempting to process the same message again. I have looked around at many different posts talking about the host.json and attempting to set those settings, but these have not worked. I have found a solution, however the solution requires your to create a clone of the message and push it back into the Service Bus and give it a delayed process time. I would prefer not to implement my own manual delay system, if Azure Service Bus / Function App can deal with retries itself.

我遇到的最大问题(这可能取决于我的理解)是谁有错?是服务总线设置来处理重试策略，还是 Azure Function App 来处理在 X 时间后尝试重试.

The biggest issue I am having (which is probably down to my understanding) is who is at fault? Is it the Service Bus settings to handle the Retry Policy or is it the Azure Function App to deal with attempting to retry after X time.

我提供了一些代码，但我觉得代码并不能真正帮助解释我的问题.

I have provided a some code, but I feel code isn't really going to help explain my question.

// Pseudo code
public static class EmailListenerTrigger
{
    [FunctionName("EmailListenerTrigger")]
    public static void Run([ServiceBusTrigger("messages", "email", Connection = "ConnectionString")]string mySbMsg, TraceWriter log)
    {
           var emailLauncher = new EmailLauncher("SmtpAddress", "SmtpPort", "FromAddress");
           try
           {
               emailLauncher.SendServiceBusMessage(mySbMsg);
           }
           catch(Exception ex)
           {
               log.Info($"Audit Log: {mySbMsg}, Excpetion: {ex.message}");
           }
    }
}

参考一:https://blog.kloud.com.au/2017/05/22/message-retry-patterns-in-azure-functions/(Thread.Sleep 似乎不是一个好主意)

reference one: https://blog.kloud.com.au/2017/05/22/message-retry-patterns-in-azure-functions/ (Thread.Sleep doesn't seem like a good idea)

参考二:https://github.com/Azure/azure-functions-host/issues/2192(手动实现重试)

reference two: https://github.com/Azure/azure-functions-host/issues/2192 (Manually implemented retry)

参考三:https://www.feval.ca/posts/function-queue-retry/(这似乎是指我使用主题时的队列)

reference three: https://www.feval.ca/posts/function-queue-retry/ (This seems to refer to queues when I am using topics)

参考四:能否Azure服务在重试消息之前总线被延迟?(谈论延迟消息，但您需要手动将其从队列/主题中取出.)

reference four: Can the Azure Service Bus be delayed before retrying a message? (Talks about Defering the message, but then you need to manually get it back out the queue/topic.)

推荐答案

您或许可以使用 Durable Functions 解决您的问题.例如，有一个内置方法 CallActivityWithRetryAsync() 可以在活动函数抛出异常时重试.

You might be able to solve your issue with the use of Durable Functions. There is for example a built-in method CallActivityWithRetryAsync() that can retry when the activity functions throws an exception.

https://docs.microsoft.com/en-us/sandbox/functions-recipes/durable-diagnostics#calling-activity-functions-with-retry

您的流程可能是这样的:

Your flow would probably something like this:

1. 服务总线触发函数.这个启动了一个 Orchestrator 函数

1. Service Bus triggered Function. This one starts an Orchestrator Function

编排器调用您的活动函数(使用上述方法)

The orchestrator calls your activity function (using the aforementioned method)

这篇关于azure 服务总线的 Azure Function App 延迟重试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！