Как Azure Event Grid обрабатывает сбой при наличии нескольких подписчиков?

Question

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

Мой вопрос: что произойдет, если имеется несколько обработчиков событий, и только один обработчик не может получить событие? Событие повторено только для этого обработчика, или все обработчики увидят повтор?

Answer 1

Как объяснил Роман, каждая конечная точка обрабатывается независимо. Если один из обработчиков событий завершится неудачно, он будет повторен без влияния на другие обработчики событий, и, конечно, если эта конкретная конечная точка продолжит отказывать, он в конечном итоге будет заблокирован (при условии, что deadlettering был настроен в подписке на событие) или будет удален.

Answer 2

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

Всякий раз, когда происходит сбой доставки события в конечную точку, она повторяется на основе настроенной политики повторных попыток. Если число повторных попыток превышает настроенную политику повторных попыток, события сохраняются в BLOB-объекте учетной записи хранения, если он настроен как пункт назначения недоставленных сообщений. иначе события будут потеряны.

По умолчанию Сетка событий истекает все события, которые не доставлены в течение 24 часов. Вы можете настроить политику повтора при создании подписки на событие. Вы указываете максимальное количество попыток доставки (по умолчанию 30) и время жизни события (по умолчанию 1440 минут).

Если имеется несколько подписчиков (подписок сетки событий) на один и тот же раздел сетки событий, повторная попытка происходит только с подпиской сетки событий, доставка события которой не удалась.

см. Доставка сообщений таблицы событий и повторите попытку для получения дополнительной информации о политике повторных попыток.

Answer 3

По сути, модель Pub / Sub событий в таблице событий Azure может работать с двумя шаблонами обмена сообщениями / передачи, такими как Fan-In и Fan-Out (широковещательная рассылка). Следующие фрагменты экрана показывают их различия:

Логическая связь между источником события и приемником события описывается подпиской, которая в основном является артефактом метаданных модели Pub / Sub. Каждая логическая связь (представленная подпиской) является независимой и слабо отделена от других. Другими словами, каждый подписчик может обрабатывать в этой модели Pub / Sub только одно логическое соединение, например, только один источник событий.

Ваш вопрос связан с шаблоном разветвления (широковещания), в котором интерес к событию передается нескольким подписчикам в режиме доставки PushWithAck. Каждая подписка в этом шаблоне разветвления имеет собственный «механизм доставки сообщений», объявленный подписчиком, такой как параметр повторных попыток, рассылка сообщений, фильтрация и т. Д.

Другими словами, доставка событий подписчикам обрабатывается параллельно на основе их подписки прозрачным способом без каких-либо зависимостей друг от друга. Обратите внимание, что у подписчика нет никакой информации о том, кто, где, как и т. Д. Один раз доставляет событие другому, поэтому каждый подписчик может видеть только собственное состояние доставки, например, значение Aeg-Delivery -Count показывает счетчик повторов конечного автомата.

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