#azure #azure-functions #azureservicebus #azure-functions-runtime
Вопрос:
Я хочу реализовать очень простое поведение в своей функции Azure: если во время обработки возникнет исключение, я хочу отложить следующую попытку на некоторое время. Насколько я знаю, для этого нет прямой возможности, например, в служебной шине (если только не создается новое сообщение), но у триггера служебной шины есть возможность ExponentialBackoffRetry .
Я не нашел никакой документации о том, как это может работать в отношении подключения к служебной шине. Т. е. что происходит с сообщением после сбоя выполнения функции.
Один из возможных способов-сохранить сообщение в инфраструктуре функций и продолжать обновлять блокировку в течение всего срока, который я предполагаю. Еще несколько практических вопросов о том, что меня интересует:
- Как долго я могу использовать повторную попытку возврата (например, если я хочу повторить попытку до 7 дней, например, будет ли это работать?)
- Что происходит, когда хост сбрасывается/перезапускается/масштабируется, теряю ли я это отступление из-за деталей реализации или оно все еще каким-то образом поддерживается?
Комментарии:
1. Вы используете функцию Azure 5.x? если да, то вы можете определить параметры для повторных настроек. Проверьте официальную документацию здесь . Параметры настройки повторной попытки предоставляют настройку для установки экспоненциальной повторной попытки.
Ответ №1:
Из документации:
Использование поддержки повторных попыток поверх устойчивости триггера
Политика повторных попыток приложения функции не зависит от любых попыток или отказоустойчивости, которые обеспечивает триггер. Политика повторной попытки функции будет накладываться только поверх устойчивой к триггеру повторной попытки. Например, при использовании служебной шины Azure по умолчанию количество доставляемых сообщений в очередях равно 10. Количество доставок по умолчанию означает, что после 10 попыток доставки сообщения очереди Служебная шина отправит сообщение в тупик. Вы можете определить политику повторных попыток для функции, у которой есть триггер служебной шины, но повторные попытки будут накладываться поверх попыток доставки по служебной шине.
Например, если вы использовали количество доставки служебной шины по умолчанию, равное 10, и определили политику повторных попыток функции, равную 5. Сначала сообщение будет снято с очереди, увеличив учетную запись доставки служебной шины до 1. Если каждое выполнение завершится неудачно, то после пяти попыток запуска одного и того же сообщения это сообщение будет помечено как оставленное. Служебная шина немедленно запросит сообщение, вызовет функцию и увеличит количество доставок до 2. Наконец, после 50 возможных попыток (10 доставок по служебной шине * пять повторных попыток для каждой доставки) сообщение будет оставлено и вызовет мертвую букву на служебной шине.
Для экспоненциальных повторных попыток вам, вероятно, потребуется сократить общее время ожидания обработки до меньшего, чем функция может удерживать сообщение, иначе срок действия блокировки истечет, и даже успешная обработка приведет к исключению и повторной попытке.
То, как Служебная шина блокирует сообщения сегодня, экспоненциальное отступление поверх служебной шины Azure-не лучшая идея. Как только станет возможным длительный срок службы (неограниченное время блокировки без необходимости продления), это будет иметь гораздо больше смысла.
Комментарии:
1. Большое спасибо за подробности, так что я правильно догадался, что хост функции выполняет автоматическое продление блокировки так долго, как это возможно? (Кстати, я не мог узнать, как долго это будет продолжаться).
2. ДА. Хотя имейте в виду, что это ограничено любой функцией, для которой вы можете работать. На премиальном плане, скорее всего, все по-другому.
3. Существуют ли какие-либо ограничения в служебной шине на то, как долго можно продлевать блокировку, или она бесконечна?
4. Жесткий предел равен 5, мягкий-бесконечен. Но я бы не стал на это рассчитывать, так как это запрос, инициированный клиентом, который может завершиться неудачей.
5. Спасибо, я уже понял (из вашего ответа), что мы не можем полностью рассчитывать на этот экспоненциальный атрибут возврата, поэтому я думаю, что один из способов решить эту проблему-добавить новое сообщение с довольно громоздким расписанием. Было бы неплохо, если бы у SB было другое решение для отсрочки обработки сообщений, так как теперь он может просто попробовать все 10 максимальных попыток за считанные секунды, если все они быстро завершатся неудачей.
Ответ №2:
Параметры повторной попытки применяются к одной операции обслуживания, выполняемой SDK служебной шины, и предназначены для того, чтобы позволить SDK обходить краткосрочные временные проблемы, такие как случайное прерывание работы сети. Помимо настройки клиентов SDK, инфраструктура функций не знает о повторных попытках и просто увидит, что SDK занимает больше времени для выполнения запрошенной операции чтения/публикации.
Инфраструктура функций будет применять любые ограничения по времени выполнения, установленные средой выполнения, или может принять решение о принятии мер для защиты от безответной работы службы. (отказ от ответственности: я могу обратиться к SDK служебной шины, но не имею глубокого представления о времени выполнения функций)
Повторные попытки из расширений служебной шины не применяются к вашему функциональному коду; при ошибке в коде вы попадете в сценарий исключения и, в зависимости от конфигурации и использования триггера/привязки, либо увидите, что ваше сообщение отменено, либо блокировка будет сохранена до истечения времени ожидания.
Я не уверен в вашем точном сценарии, но, похоже, вы, возможно, захотите отложить чтение сообщения явно на более позднее время или повторно поставить сообщение в очередь по расписанию, чтобы функция могла прочитать его снова в определенный момент в будущем.
Комментарии:
1. Большое спасибо за советы, я понятия не имел, что мы можем отложить, я проверю это подробнее. Мой сценарий прост: я хочу, чтобы сообщение было надежно обработано даже в случае простоя служб, с которыми разговаривает функция. Т. Е. Я хочу отложить выполнение, если оно не удалось, на несколько дней. Вы уверены, что экспоненциальный откат не применяется? Согласно ответу Шона Фельдмана, он действительно обновляет блокировку, если я все понял правильно, и документы, которые он опубликовал, похоже, предполагают то же самое.
2. Кстати, есть ли способ читать отложенные сообщения с помощью функции Azure? Похоже, они приходят не «обычным» способом
3. Я уверен, что в контексте конфигурации настроек повторной попытки; это напрямую относится к набору
ServiceBusOptions, используемому для создания клиентов, что и было моим предположением, основанным на комментарии к вашему сообщению. Тем не менее, если мы говорим об атрибуте ExponentialRetryBackoff (что при повторном прочтении вашего поста кажется более вероятным), то ответ Шона на 100% верен и более применим. Приношу извинения за любую путаницу.4. Я не знаю способа чтения отложенных сообщений, полученных непосредственно триггером (хотя он может существовать, и я просто не знаю) В прошлом, когда мне это было необходимо, я сохранял свои отложенные порядковые номера в хранилище данных вместе со временем, на которое я хотел отложить. Я запустил свою функцию на триггере таймера и использовал эти данные с клиентом служебной шины в теле функции для обработки.
5. Спасибо за помощь, похоже, что атрибут экспоненциального отката не является идеальным способом справиться с ситуациями длительного простоя. Тогда либо ваш трюк, либо, возможно, отправка нового сообщения в служебную шину с расписанием может сделать свое дело. Жаль, однако, что служебная шина не поддерживает новое расписание для существующего сообщения. Это кажется очень ценной функцией, так как прямо сейчас все 10 попыток можно повторить за очень короткий промежуток времени.