Отправка сообщений и повторная попытка с разделами пространства имен

Push-доставка пространства имен Event Grid обеспечивает надежную доставку. Сервис Event Grid пытается доставить каждое сообщение хотя бы один раз для каждой соответствующей подписки немедленно. Если конечная точка подписчика не подтверждает получение события или произошла ошибка, Сетка событий повторяет попытку доставки на основе предопределенного расписания повтора и политики повтора. По умолчанию Служба "Сетка событий" передает одно событие в одно время подписчику.

Подписка на события

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

Расписание повторных попыток

Когда сетка событий получает ошибку для попытки доставки событий, сетка событий решает, следует ли повторить доставку на основе типа ошибки.

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

Условия:

• ArgumentException
• TimeoutException
• UnauthorizedAccessException
• OperationCanceledException
• SocketException |

Коды ошибок

• 404 - NotFound
• 401 - Unauthorized
• 403 - Forbidden
• 400 -BadRequest
• 414 RequestUriTooLong

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

• 0 секунд (немедленная повторная попытка)
• 10 секунд
• 30 секунд
• 1 минута
• 5 мин

Через 5 минут Event Grid продолжает повторять попытки каждые 5 минут до тех пор, пока событие не будет доставлено или не будет достигнуто максимальное количество попыток, или время жизни события.

Политика повторных попыток

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

• Максимальное число доставки — значение должно быть целым числом от 1 до 10. Значение по умолчанию — 10. Для принудительной доставки это свойство определяет максимальное количество попыток доставки.
• Хранение — это свойство также называется event time to live. Значение должно быть значением длительности ISO 8601 с точностью минуты. Начиная с момента публикации события это свойство определяет интервал времени, после которого истекает срок действия сообщения. Минимально допустимое значение — "PT1M" (1 минута). Максимально допустимое значение — 7 дней или время хранения базового раздела, в зависимости от того, что меньше. Портал Azure предоставляет простой пользовательский интерфейс, в котором указываются дни, часы и минуты в виде целых чисел.

Пакетная обработка выходных данных

Если Webhooks используются как тип конечной точки назначения, Сетка событий по умолчанию отправляет каждое событие отдельно подписчикам. Event Grid можно настроить для пакетирования событий с целью улучшения производительности HTTP в условиях высокой загрузки. Пакетная обработка отключена по умолчанию и может быть включена для каждой подписки на события.

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

Политика пакетной обработки

У пакетной доставки есть два параметра:

• Максимальное количество событий на пакет — максимальное число событий сетки событий доставляется на каждый пакет. Значение должно быть целым числом от 1 до 5 000. Это число никогда не превышается. Однако меньше событий может быть доставлено, если больше событий не доступно во время доставки. Если доступно меньше событий, чем указано в параметре, Сетка событий не будет задерживать события для создания пакета.
• Предпочтительный размер пакета в килобайтах — целевой размер пакета в килобайтах. Значение должно быть числом от 1 до 1024. Как и в случае с максимальным числом событий, размер пакета может быть меньше, если в момент доставки событий их недостаточно. Пакет может быть больше предпочтительного размера, если размер одного события превышает значение этого параметра. Например, если предпочтительный размер равен 4 КБ, а событие 10 КБ отправляется в сетку событий, то событие 10 КБ доставляется, а не удаляется.

Пакетная доставка настраивается для каждой подписки на события с помощью портала, интерфейса командной строки, PowerShell или пакетов SDK.

Поведение пакетной обработки

• Всё или ничего

  Сервис Event Grid работает по принципу "всё или ничего". Она не поддерживает частичное выполнение пакетной доставки. Подписчикам следует быть осторожными и запрашивать только столько событий на пакет, сколько они смогут обработать в течение 30 секунд.

• Оптимистичная пакетная обработка

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

• По умолчанию параметр установлен на ВЫКЛ.

  По умолчанию Сетка событий добавляет только одно событие в каждый запрос на доставку. Способ включения пакетной обработки — задать один из параметров, упомянутых в политике пакетной обработки.

• Значения по умолчанию

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

Портал Azure

Эти параметры отображаются на вкладке "Дополнительные функции " на странице "Подписка на события " или после создания подписки на событие в меню "Конфигурация" при доступе к подписке на события.

События недоставленных сообщений

Если сетка событий не может доставлять событие в течение определенного периода времени или после попытки доставки события определенное количество раз, оно отправляет событие в учетную запись хранения. Этот процесс называется мертвое письмо. Сервис Event Grid перемещает событие в очередь недоставленных при выполнении одного из следующих условий:

• Событие не доставляется в течение периода действия (срок хранения, установленный в подписке на событие).
• Количество попыток доставки события превысило ограничение.

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

Служба Event Grid отправляет событие в место, предназначенное для необработанных сообщений, когда все попытки повторной доставки исчерпаны. Если Сетка событий получает код ответа 400 (ошибка запроса) или 413 (слишком большой запрос), она немедленно планирует отправку события в очередь недоставленных сообщений. Эти коды ответа указывают, что доставка события никогда не будет выполнена успешно.

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

Существует 5-минутная задержка между последней попыткой доставки события и его отправкой в очередь недоставленных писем. Эта задержка предназначена для уменьшения числа операций работы с Blob-хранилищем. Если место назначения недоставленных сообщений недоступно в течение четырех часов, событие удаляется.

Прежде чем задать расположение для dead-letter, необходимо создать учетную запись хранения с контейнером. При создании подписки на событие необходимо ввести конечную точку для этого контейнера. Конечная точка имеет следующий формат: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Вы можете захотеть получать уведомления, когда событие было отправлено в расположение мёртвого письма. Чтобы использовать Event Grid для реагирования на недоставленные события, создайте подписку на события для хранилища dead-letter событий. Каждый раз, когда ваше хранилище больших двоичных объектов недоставленных сообщений получает недоставленное событие, служба "Сетка событий Azure" уведомляет вашего обработчика. Обработчик отвечает действиями, которыми вы хотите воспользоваться для урегулирования недоставленных событий.

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

Форматы событий доставки

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

Схема CloudEvents 1.0

Event

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Событие недоставленного сообщения

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Испытательный срок

Подписка на события переводится в испытательный режим Event Grid на некоторое время, если доставку событий в пункт назначения невозможно осуществить. Испытательный срок отличается для разных ошибок, возвращаемых целевой конечной точкой. Если подписка на событие находится на проверке, события могут попасть в очередь недоставленных сообщений или быть удалены без попытки доставки в зависимости от кода ошибки, из-за которого она на проверке.

Состояние доставки сообщения

Сетка событий использует коды ответов HTTP для подтверждения получения событий.

Коды успешной доставки

В Сетке событий успешной доставкой считаются только следующие коды ответов HTTP. Все остальные коды состояния считаются неудачной доставкой и будут повторены или обработаны как dead-letter соответствующим образом. Если Сетка событий получает успешный код состояния, она считает доставку завершенной.

• 200 OK (Запрос выполнен успешно)
• 201 Создано
• 202 Принято
• 203 — не заслуживающая доверия информация
• 204 Нет контента

Коды ошибок

Все остальные коды, не указанные в приведенном выше наборе (200-204), считаются неудачными и будут повторно выполнены при необходимости. Некоторые из них связаны с конкретными политиками повторных попыток, описанными ниже, все остальные следуют стандартному расписанию повторных попыток. Важно помнить, что из-за высокой параллелизации архитектуры сетки событий поведение повторных попыток не детерминировано.

Настраиваемые свойства доставки

Подписки на события позволяют настраивать заголовки HTTP, которые включаются в доставляемые события. Благодаря этой возможности вы можете задавать пользовательские заголовки, требуемые местом назначения. При создании подписки на событие можно задать до 10 заголовков. Каждое значение заголовка не должно превышать 4 096 (4 КБ). Пользовательские заголовки можно задавать для событий, которые доставляются в следующие местоположения:

• Webhooks
• Центры событий Azure

Дальнейшие действия

• Доставка событий на конечные точки веб-хуков.