Функции Azure со служебной шиной: как сохранить сообщение в очереди, если с его обработкой что-то пойдет не так?

Я новичок в служебном автобусе и не могу понять этого.

В основном я использую приложение-функцию Azure, которое подключено к очереди служебной шины. Допустим, из служебной шины срабатывает триггер, и я получаю сообщение из очереди, и при обработке этого сообщения что-то идет не так в моем коде. В таких случаях, как мне убедиться, что это сообщение снова помещено в очередь? В настоящее время он просто исчезает в воздухе, и когда я перезапускаю свое приложение-функцию на VS, берется следующее сообщение из очереди.

В идеале, только когда вся моя обработка данных завершена и когда я нажимаю myMsg.Success (), я хочу, чтобы он был удален из очереди.

public static async Task RunAsync([ServiceBusTrigger("xx", "yy", AccessRights.Manage)]BrokeredMessage mySbMsg, TraceWriter log)
{
      try{ // do something with mySbMsg }

      catch{ // put that mySbMsg back in the queue so it doesn't disappear. and throw exception}
}

Я читал mySbMsg.Abandon (), но похоже, что это помещает сообщение в очередь недоставленных сообщений, и я не уверен, как получить к нему доступ? а есть ли лучший способ обработки ошибок?


azure c# azureservicebus azure-functions azure-servicebus-queues
person 90abyss    schedule 26.01.2018    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Облачные очереди немного отличаются от очередей в памяти, потому что они должны быть устойчивыми к возможности сбоя клиента после того, как он получил сообщение очереди, но до того, как он завершил обработку сообщения.

При получении сообщения очереди оно становится «невидимым», так что другие клиенты не могут его забрать. Это дает клиенту возможность обработать его, и клиент должен пометить его как завершенный, когда это будет сделано (Функции Azure сделают это автоматически, когда вы вернетесь из функции). Таким образом, если клиент выйдет из строя в середине обработки сообщения (мы находимся в облаке, поэтому будьте устойчивы к случайным сбоям машины из-за потери мощности и т. Д.), Сервер увидит отсутствие завершенного сообщения, предположим сбой клиента и, в конечном итоге, повторная отправка сообщения.

Фактически это означает, что если вы получаете сообщение очереди и генерируете исключение (и, таким образом, мы не отмечаем сообщение как завершенное), оно будет невидимым в течение нескольких минут, но затем снова появится через несколько минут. и другой клиент может попытаться справиться с этим. Другими словами, в функциях Azure сообщения очереди автоматически повторяются после исключений, но сообщение будет невидимым в течение нескольких минут между повторными попытками.

person Mike S    schedule 26.01.2018
comment
Следует отметить, что время ожидания начальной блокировки для сообщений, выходящих из очереди служебной шины, настраивается на уровне очереди. Итак, зная, что Функции Azure работают таким образом, если тайм-аут видимости по умолчанию (30 секунд IIRC) для вас слишком велик, просто верните его к более приемлемому значению для вашего домена. - person Drew Marsh; 26.01.2018
comment
Очередь будет поддерживать либо режим FIFO, либо конкурирующих потребителей, но не режим LIFO. - person Sean Feldman; 26.01.2018
comment
@SeanFeldman - ты прав. Я просто убрал этот термин из своего ответа, это был неправильный термин. - person Mike S; 27.01.2018

arrow_upward
0
arrow_downward

Если вы хотите, чтобы сообщение оставалось в очереди для повторной попытки, функция не должна проглатывать исключение, а скорее выбрасывать. В этом случае функция не будет автоматически завершать сообщение и повторять его.

Имейте в виду, что это приведет к повторной попытке сообщения и, в конечном итоге, если исключение не исчезнет, ​​он будет перемещен в очередь недоставленных сообщений.

person Sean Feldman    schedule 26.01.2018
comment
Это не работает на V2. Функции - это вызовет перезапуск хоста функций. - person David Lapeš; 15.01.2019
comment
Вот как работает ASB и что использует триггер ... Звуки того, что хост перезапустится, если сообщение не будет обработано. Вы подняли вопрос? - person Sean Feldman; 15.01.2019

arrow_upward
0
arrow_downward

Насколько я понимаю, я думаю, что вам нужно, если при обработке сообщения возникает ошибка, и ему нужно повторить попытку выполнения вместо того, чтобы проглотить его. Если вы используете Функции Azure V2.0, вы определяете параметры обработчика сообщений в host.json

 "extensions": {
        "serviceBus": {
            "prefetchCount": 100,
            "messageHandlerOptions": {
                "autoComplete": false,
                "maxConcurrentCalls": 1
            }
        }
    }

prefetchCount - получает или задает количество сообщений, которые получатель сообщения может одновременно запросить.

autoComplete - должен ли триггер автоматически вызывать завершение после обработки или код функции вручную вызывает завершение.

После повторных попыток отправки сообщения n (по умолчанию 10) раз сообщение будет передано в DLQ.

person Hari Krishna    schedule 05.06.2020