Доставка и повторные попытки доставки сообщений сетки событий

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

Расписание повторной доставки

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

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

В следующей таблице описаны типы конечных точек и ошибок, для которых не выполняется повторная попытка отправки:

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

Сетка событий ожидает ответа в течение 30 секунд после доставки сообщения. Через 30 секунд, если конечная точка не ответила, сообщение помещается в очередь для повторной попытки. Для доставки событий сетка событий использует политику экспоненциального увеличения задержки повтора. Сетка событий повторяет попытку доставки по следующему расписанию, составленному из принципа эффективного использования ресурсов:

• 10 seconds
• 30 секунд
• 1 минута
• 5 мин
• 10 минут
• 30 минут
• 1 ч
• 3 часов
• 6 часов
• Каждые 12 часов до 24 часов

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

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

Политика повтора

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

• Максимальное число попыток. Значение должно быть целым числом от 1 до 30. Значение по умолчанию — 30.
• Срок жизни события (TTL) — значение должно быть целым числом в диапазоне от 1 до 1440. Значение по умолчанию — 1440 минут.

Пример использования команды интерфейса командной строки и PowerShell для настройки этих параметров см. в разделе Настройка политики повторов.

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

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

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

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

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

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

Логика работы пакетной обработки

• Принцип All-or-none

  "Сетка событий" работает с семантикой all-or-none (все полностью или ничего). Она не поддерживает частичное выполнение пакетной доставки. Подписчики должны быть осторожны, чтобы запрашивать только столько событий на пакет, сколько они могут обрабатывать в 30 секундах.

• Оптимизация пакетной обработки

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

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

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

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

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

Портал Azure:

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

Azure CLI

При создании подписки на события используйте следующие параметры:

• max-events-per-batch — максимальное число событий в пакете. Это значение должно быть в диапазоне от 1 до 5000.
• preferred-batch-size-in-kilobytes — предпочтительный размер пакета в килобайтах. Это значение должно быть в диапазоне от 1 до 1024.

storageid=$(az storage account show --name <storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
endpoint=https://$sitename.azurewebsites.net/api/updates

az eventgrid event-subscription create \
  --resource-id $storageid \
  --name <event_subscription_name> \
  --endpoint $endpoint \
  --max-events-per-batch 1000 \
  --preferred-batch-size-in-kilobytes 512

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

Отложенная доставка

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

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

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

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

• событие не доставлено в течение срока жизни;
• число попыток доставки события превысило предельное значение.

Если одно из условий соблюдается, событие удаляется или помещается в очередь недоставленных сообщений. По умолчанию в службе "Сетка событий Azure" не включено перемещение в очередь недоставленных сообщений. Чтобы его включить, необходимо указать учетную запись хранения недоставленных событий при создании подписки на событие. Можно извлекать события из этой учетной записи хранения, чтобы продолжать доставку.

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

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

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

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

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

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

В этом разделе приведены примеры событий и событий, отправленных в очередь недоставленных сообщений, в различных форматах схемы доставки (схема Сетки событий, схема CloudEvents 1.0 и пользовательская схема). Дополнительные сведения об этих форматах см. в статьях Схема Сетки событий и Cloud Events 1.0.

Схема Сетки событий

Мероприятие

{
    "id": "93902694-901e-008f-6f95-7153a806873c",
    "eventTime": "2020-08-13T17:18:13.1647262Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "dataVersion": "",
    "metadataVersion": "1",
    "topic": "/subscriptions/000000000-0000-0000-0000-00000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
    "subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",    
    "data": {
        "api": "PutBlob",
        "clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
        "requestId": "93902694-901e-008f-6f95-7153a8000000",
        "eTag": "0x8D83FACDC0C3402",
        "contentType": "text/plain",
        "contentLength": 0,
        "blobType": "BlockBlob",
        "url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
        "sequencer": "00000000000000000000000000015508000000000005101c",
        "storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
    }
}

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

{
    "id": "93902694-901e-008f-6f95-7153a806873c",
    "eventTime": "2020-08-13T17:18:13.1647262Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "dataVersion": "",
    "metadataVersion": "1",
    "topic": "/subscriptions/0000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
    "subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",    
    "data": {
        "api": "PutBlob",
        "clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
        "requestId": "93902694-901e-008f-6f95-7153a8000000",
        "eTag": "0x8D83FACDC0C3402",
        "contentType": "text/plain",
        "contentLength": 0,
        "blobType": "BlockBlob",
        "url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
        "sequencer": "00000000000000000000000000015508000000000005101c",
        "storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
    },

    "deadLetterReason": "MaxDeliveryAttemptsExceeded",
    "deliveryAttempts": 1,
    "lastDeliveryOutcome": "NotFound",
    "publishTime": "2020-08-13T17:18:14.0265758Z",
    "lastDeliveryAttemptTime": "2020-08-13T17:18:14.0465788Z" 
}

Ниже приведены возможные значения lastDeliveryOutcome и их описание.

LastDeliveryOutcome: Probation

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

Схема CloudEvents 1.0

Мероприятие

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

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

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

    "deadletterreason": "MaxDeliveryAttemptsExceeded",
    "deliveryattempts": 1,
    "lastdeliveryoutcome": "NotFound",
    "publishtime": "2020-08-13T21:21:36.4018726Z",
}

Пользовательская схема

Мероприятие

{
    "prop1": "my property",
    "prop2": 5,
    "myEventType": "fooEventType"
}

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

{
    "id": "8bc07e6f-0885-4729-90e4-7c3f052bd754",
    "eventTime": "2020-08-13T18:11:29.4121391Z",
    "eventType": "myEventType",
    "dataVersion": "1.0",
    "metadataVersion": "1",
    "topic": "/subscriptions/00000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.EventGrid/topics/myCustomSchemaTopic",
    "subject": "subjectDefault",
  
    "deadLetterReason": "MaxDeliveryAttemptsExceeded",
    "deliveryAttempts": 1,
    "lastDeliveryOutcome": "NotFound",
    "publishTime": "2020-08-13T18:11:29.4121391Z",
    "lastDeliveryAttemptTime": "2020-08-13T18:11:29.4277644Z",
  
    "data": {
        "prop1": "my property",
        "prop2": 5,
        "myEventType": "fooEventType"
    }
}

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

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

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

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

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

Коды сбоя доставки

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

Пользовательские свойства доставки

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

• Веб-перехватчики
• Разделы и очереди служебной шины Azure;
• Центры событий Azure
• Гибридные подключения Relay.

Дополнительные сведения см. в разделе Пользовательские свойства доставки.

Следующие шаги

• Сведения о том, как просмотреть состояние доставки событий, см. в статье Мониторинг доставки сообщений Сетки событий.
• Чтобы настроить параметры доставки событий, см. в разделе Недоставленные сообщения и политики повтора.