В документации для Event Grid указано, что он имеет доставку и встроенный механизм повторных попыток и дает пример того, что можно классифицировать как успешную или неудачную попытку. Документация очень четко описывает, что происходит с одним обработчиком событий.
Мой вопрос: что произойдет, если есть несколько обработчиков событий, и только один обработчик не может получить событие? Событие повторяется только для этого обработчика или все обработчики увидят повторную попытку?
По сути, модель Pub/Sub обработки событий Azure Event Grid может обрабатывать два шаблона обмена сообщениями/посредничества, например шаблон Fan-In и шаблон Fan-Out (широковещательная рассылка). Следующие фрагменты экрана показывают их различия:
Логическая связь между источником событий и приемником событий описывается подпиской, которая в основном является артефактом метаданных модели Pub/Sub. Каждая логическая связь (представленная подпиской) независима и слабо связана с другими. Другими словами, каждый подписчик может обрабатывать в этой модели Pub/Sub только одно логическое соединение, например, только один источник событий.
Ваш вопрос связан с шаблоном разветвления (трансляции), когда интерес к событию передается нескольким подписчикам с использованием режима доставки PushWithAck. Каждая подписка в рамках этого шаблона разветвления имеет собственную «машину доставки состояния сообщения», объявленную подписчиком, например, возможность повторной попытки, удаление недоставленных сообщений, фильтрацию и т. д.
Другими словами, доставка событий подписчикам обрабатывается параллельно на основе их подписки прозрачным образом без какой-либо зависимости друг от друга. Обратите внимание, что подписчик не имеет никакой информации о том, кто, где, как и т. д. доставляет событие другому один раз, поэтому каждый подписчик может видеть только свое состояние доставки, например, значение параметра Aeg-Delivery. -Count показывает счетчик повторных попыток конечного автомата.
Таким образом, в случае неудачной доставки события одному из нескольких подписчиков включенный процесс повторной попытки выполняется только для этого подписчика.
Как объяснил Роман, каждая конечная точка обрабатывается независимо. Если один обработчик событий дает сбой, он будет предпринят повторно, не затрагивая другие обработчики событий, и, конечно, если эта конкретная конечная точка продолжит сбой, она в конечном итоге будет помечена как недоставленная (при условии, что в подписке на событие настроена недооценка) или удалена.
При публикации событий в сетках событий события из настраиваемых тем сетки событий или тем системных сеток событий (например, пространств имен служебной шины) перенаправляются в настроенные с ними подписки сетки событий. Затем события отправляются на конечные точки, для которых настроена подписка на сетку событий.
При сбое доставки события в конечную точку выполняется повторная попытка на основе настроенной политики повторных попыток. Если количество повторных попыток превышает настроенную политику повторных попыток, события сохраняются в большом двоичном объекте учетной записи хранения, если он события будут потеряны.
По умолчанию в сетке событий истекает срок действия всех событий, которые не были доставлены в течение 24 часов. Вы можете настроить политику повторных попыток при создании подписки на события. Вы указываете максимальное количество попыток доставки (по умолчанию — 30) и время жизни события (по умолчанию — 1440 минут).
При наличии нескольких подписчиков (подписок на сетку событий) на одну и ту же тему сетки событий повторная попытка выполняется только для той подписки на сетку событий, доставка события которой не удалась.
см. доставку сообщений сетки событий и повторную попытку для Дополнительные сведения о политике повторных попыток.
