Entrega por push de mensagem e repetição com tópicos de namespace

A entrega por push dos namespaces da Grade de Eventos fornecem entrega durável. A Grade de Eventos tenta entregar cada mensagem pelo menos uma vez para cada assinatura correspondente imediatamente. Se o ponto de extremidade de um assinante não confirmar o recebimento de um evento ou se houver uma falha, a Grade de Eventos tentará a entrega novamente com base em uma agenda de repetição e em uma política de repetição. Por padrão, a Grade de Eventos entrega um evento de cada vez ao assinante.

Observação

A Grade de Eventos não garante a ordem de entrega de eventos, portanto, os assinantes podem recebê-los fora de ordem.

Assinatura do evento

Uma assinatura de evento é um recurso de configuração associado a apenas um tópico de namespace. Entre outras coisas, você usa uma assinatura de evento para definir critérios de seleção de eventos a fim de definir a coleção de eventos disponível para um assinante do conjunto total de eventos disponíveis em um tópico. Usando uma assinatura de evento, você também define o ponto de extremidade de destino para o qual os eventos são enviados. Além disso, uma assinatura de evento permite que você defina outras propriedades, como a contagem máxima de repetição de entrega e o tempo de vida útil dos eventos, que definem o comportamento de runtime da entrega de eventos.

Agenda de repetição

Quando a Grade de Eventos recebe um erro para uma tentativa de entrega de eventos, a Grade de Eventos decide se deve fazer uma nova tentativa de realizar a entrega com base no tipo do erro.

Se o erro retornado pelo ponto de extremidade assinado for um erro relacionado à configuração que não pode ser corrigido com novas tentativas, a Grade de Eventos enviará o evento para um destino de mensagens mortas configurado. Se nenhum armazenamento de mensagens mortas estiver configurado, o evento será removido. Por exemplo, um evento é colocado na fila de mensagens mortas ou descartado quando o ponto de extremidade configurado na assinatura do evento não pode ser atingido porque foi excluído. A repetição da tentativa de entrega não ocorre para as seguintes condições e erros:

Condições:

• ArgumentException
• TimeoutException
• UnauthorizedAccessException
• OperationCanceledException
• SocketException |

Códigos de erro

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

Observação

Se o armazenamento de mensagens mortas não estiver configurado para um ponto de extremidade, os eventos serão removidos quando os erros ou condições acima ocorrerem. Considere configurar o armazenamento de mensagens mortas em sua assinatura de evento se você não quiser que esses tipos de eventos sejam removidos. Eventos com mensagens mortas serão descartados quando o destino da mensagem morta não for encontrado.

Se a condição ou o erro retornado pelo ponto de extremidade assinado não estiver entre os indicados nas listas acima, a Grade de Eventos tentará novamente em uma base de esforço básico usando o seguinte agendamento novas tentativas de retirada exponencial:

• 0 segundos (nova tentativa imediata)
• 10 segundos
• 30 segundos
• 1 minuto
• 5 minutos

Após 5 minutos, a Grade de Eventos continua a tentar novamente a cada 5 minutos até que o evento seja entregue ou a contagem máxima de repetições ou a vida útil do evento seja atingida.

Política de Repetição

Você pode personalizar a política de repetição usando as duas propriedades de configuração de assinatura de evento a seguir. Um evento será descartado (nenhum armazenamento em mensagens mortas configurado) ou colocado na fila de mensagens mortas se uma das propriedades atingir o limite configurado.

• Contagem máxima de entrega – o valor deve ser um inteiro entre 1 e 10. O valor padrão é 10. Para entrega por push, essa propriedade define o máximo de tentativas de entrega.
• Retenção – Essa propriedade também é conhecida como event time to live. O valor precisa ser um valor de duração ISO 8601 com precisão de minuto. A partir do momento em que o evento foi publicado, essa propriedade define o período de tempo após o qual a mensagem expira. O valor mínimo permitido é "PT1M" (1 minuto). O valor máximo permitido é de sete dias ou o tempo de retenção do tópico subjacente, o que for menor. O portal do Azure fornece uma experiência de usuário simples em que você especifica os dias, horas e minutos como inteiros.

Observação

Se você definir ambos Retention e Maximum delivery count, a Grade de Eventos usa-os para determinar quando parar a entrega de eventos. Qualquer um deles interrompe a entrega de eventos. Por exemplo, se você definir 20 minutos como retenção e dez tentativas máximas de entrega, isso significa que, quando um evento não for entregue após 20 minutos ou não for entregue após dez tentativas, o que acontecer primeiro, o evento será colocado na fila de mensagens mortas. No entanto, devido ao agendamento de repetição, definir o número máximo de tentativas de entrega como 10 não tem impacto, pois os eventos serão gravados na fila de mensagens mortas primeiro após 20 minutos. Isso ocorre devido ao fato de que, no minuto 20, a tentativa de entrega nº 8 (0, 10s, 30s, 1m, 5m, 10m, 15m, 20m) ocorre, mas nesse momento o evento é colocado na fila de mensagens mortas.

Envio em lote de saída

Quando você usa Webhooks como o tipo de ponto de extremidade de destino, a Grade de Eventos usa o padrão de enviar cada evento individualmente aos assinantes. Você pode configurar a Grade de Eventos para eventos em lote para entrega a fim de obter desempenho de HTTP aprimorado em cenários de alta taxa de transferência. O envio em lote é desativado por padrão e pode ser ativado para cada assinatura de evento.

Ao usar os Hubs de Eventos como tipo de ponto de extremidade de destino, a Grade de Eventos sempre agrupa eventos em lotes para o máximo de eficiência e desempenho. Não há nenhuma configuração de política em lote disponível, pois, por padrão, a Grade de Eventos manipula o comportamento de envio em lote ao entregar aos Hubs de Eventos do Azure.

Política de envio em lote

A entrega em lote tem duas configurações:

• Máximo de eventos por lote: número máximo de eventos que a Grade de Eventos entrega por lote. O valor precisa ser um número inteiro entre 1 e 5.000. Esse número nunca é excedido. No entanto, menos eventos poderão ser entregues se não houver mais eventos disponíveis no momento da entrega. A Grade de Eventos não atrasará eventos de criação de lote se menos eventos estiverem disponíveis.
• Tamanho de lote preferencial em quilobytes – O limite de destino do tamanho do lote em quilobytes. O valor precisa ser um número entre 1 e 1024. Semelhante ao máximo de eventos, o tamanho do lote poderá ser menor se não houver eventos suficientes disponíveis no momento da entrega. É possível que um lote seja maior do que o tamanho de lote preferencial se um evento for maior do que o tamanho preferencial. Por exemplo, se o tamanho preferencial for 4 Kb e um evento de 10 Kb for enviado por push para a Grade de Eventos, o evento de 10 Kb será entregue em vez de ser removido.

A entrega em lote é configurada por assinatura de evento por meio do portal, da CLI, do PowerShell ou de SDKs.

Comportamento de envio em lote

• Tudo ou nada

  A Grade de Eventos opera com a semântica tudo ou nada. Ela não dá suporte ao sucesso parcial de uma entrega em lote. Os assinantes devem ter o cuidado de solicitar apenas a quantidade de eventos por lote que puderem processar em 30 segundos.

• Envio em lote otimista

  As configurações de política de envio em lote não são limites estritos no comportamento de envio em lote e são respeitadas com base no melhor esforço. Com taxas de eventos baixas, geralmente você observará que o tamanho do lote é menor do que o máximo de eventos solicitados por lote.

• O padrão é definido como OFF

  Por padrão, a Grade de Eventos adiciona apenas um evento a cada solicitação de entrega. A maneira de ativar o envio em lote é definir uma das configurações mencionadas na Política de envio em lote.

• Valores padrão

  Não é necessário especificar as configurações (máximo de eventos por lote e tamanho de lote aproximado em quilobytes) ao criar uma assinatura de evento. Se apenas uma configuração for definida, a Grade de Eventos usará valores padrão. Confira as seções a seguir para obter os valores padrão e como substituí-los.

Portal do Azure

Você verá essas configurações na guia Recursos Adicionais da página Assinatura de Eventos ou depois que a assinatura do evento for criada, na opção de menu Configuração ao acessar a Assinatura de Evento.

Eventos de mensagens mortas

Quando a Grade de Eventos não puder entregar um evento dentro de um determinado período ou depois de tentar entregar o evento um determinado número de vezes, ela enviará o evento a uma conta de armazenamento. Esse processo é conhecido como armazenamento de mensagens mortas. A Grade de Eventos armazena mensagens mortas de um evento quando uma das condições a seguir é atendida.

• O evento não é entregue dentro do período de vida útil (retenção definida na assinatura do evento).
• O número de tentativas de entrega do evento excedeu o limite.

Se qualquer uma das condições for atendida, o evento será removido ou armazenado como mensagem morta. Por padrão, a Grade de Eventos não ativa o armazenamento de mensagens mortas. Para habilitá-lo, você deve especificar uma conta de armazenamento para reter eventos que não foram entregues ao criar a assinatura do evento. Você aciona eventos dessa conta de armazenamento para resolver as entregas.

A Grade de Eventos enviará um evento ao local de mensagens mortas quando ela tiver tentado todas as suas tentativas de repetição. Se a Grade de Eventos receber um código de resposta 400 (Solicitação Inválida) ou 413 (Entidade de Solicitação Muito Grande), ela agendará imediatamente o evento para o armazenamento de mensagens mortas. Esses códigos de resposta indicam que a entrega do evento nunca terá êxito.

O término da vida útil é verificado APENAS na próxima tentativa de entrega agendada. Portanto, mesmo se a vida útil expirar antes da próxima tentativa de entrega agendada, a expiração do evento será verificada somente no momento da próxima entrega e o armazenamento de mensagens mortas será realizado em seguida.

Há um atraso de cinco minutos entre a última tentativa de entrega de um evento e quando ele é entregue para o local de inatividade. Esse atraso tem como objetivo reduzir o número de operações de Armazenamento de Blobs. Se o local de mensagens mortas não estiver disponível por quatro horas, o evento será descartado.

Antes de configurar o local de mensagens mortas, você deve ter uma conta de armazenamento com um contêiner. É possível fornecer o ponto de extremidade para esse contêiner ao criar a assinatura do evento. O ponto de extremidade está no formato de: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Talvez você queira ser notificado quando um evento tiver sido enviado para a localização das mensagens mortas. Para usar a Grade de Eventos para responder a eventos não entregues, crie uma assinatura de evento para o armazenamento de blob de mensagens mortas. Toda vez que seu armazenamento de blob de mensagens mortas recebe um evento não entregue, a Grade de Eventos notifica o manipulador. O manipulador responde com ações que você deseja executar para reconciliar eventos não entregues.

Ao configurar o armazenamento em mensagens mortas, você precisará adicionar a identidade gerenciada à função RBAC (controle de acesso baseado em função) apropriada na conta de Armazenamento do Azure que conterá os eventos armazenados como mensagens mortas. Para obter mais informações, consulte Funções do Azure e destinos compatíveis.

Formatos de evento de entrega

Esta seção fornece exemplos de eventos e eventos armazenados como mensagens mortas usando o esquema CloudEvents 1.0, o formato de metadados de mensagem com suporte nos tópicos do namespace.

Esquema do CloudEvents 1.0

Evento

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

Evento de mensagens mortas

[
  {
    "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: Avaliação

Uma assinatura de evento será colocada em avaliação por uma duração pela Grade de Eventos se as entregas de eventos para esse destino começarem a falhar. O tempo de avaliação é diferente para erros diferentes retornados pelo ponto de extremidade de destino. Se uma assinatura de evento estiver em avaliação, os eventos poderão receber mensagens mortas ou descartadas sem nem mesmo tentar a entrega, dependendo do código de erro, devido ao qual ela está em avaliação.

Erro	Duração da avaliação
Ocupado	10 segundos
NotFound	5 minutos
SocketError	30 segundos
ResolutionError	5 minutos
Desabilitado	5 minutos
Completo	5 minutos
TimedOut	10 segundos
Não Autorizado	5 minutos
Proibido	5 minutos
InvalidAzureFunctionDestination	10 minutos

Observação

A Grade de Eventos usa a duração da avaliação para um melhor gerenciamento de entrega e a duração pode mudar no futuro.

Status de entrega da mensagem

A Grade de Eventos usa códigos de resposta HTTP para confirmar o recebimento de eventos.

Códigos de sucesso

A Grade de Eventos considera apenas os códigos de resposta HTTP a seguir como entregas bem-sucedidas. Todos os outros códigos de status são considerados entregas com falha e serão repetidos ou armazenados como mensagens mortas, conforme apropriado. Quando a Grade de Eventos recebe um código de status bem-sucedido, considera a entrega concluída.

• 200 OK
• 201 Criado
• 202 Aceito
• 203 Informações Não Autoritativas
• 204 Sem Conteúdo

Códigos de falha

Todos os outros códigos que não estão no conjunto acima (200 a 204) são considerados falhas e serão repetidos, se necessário. Alguns têm políticas de repetição específicas ligadas a eles descritas abaixo e todos os outros seguem o agendamento de repetição padrão. É importante ter em mente que, devido à natureza altamente paralelizada da arquitetura da Grade de Eventos, o comportamento de repetição é não determinístico.

Código de status	Tentar comportamento novamente
400 Solicitação Inválida	Não tentar novamente
401 Não Autorizado	Tentar novamente após cinco minutos ou mais para os Pontos de Extremidade de Recursos do Azure
403 Proibido	Não tentar novamente
404 Não Encontrado	Tentar novamente após cinco minutos ou mais para os Pontos de Extremidade de Recursos do Azure
408 Tempo Limite da Solicitação	Tentar novamente após dois minutos ou mais
Solicitação 413 entidade muito grande	Não tentar novamente
503 Serviço Indisponível	Tentar novamente após 30 segundos ou mais
Todos os outros	Tentar novamente após dez segundos ou mais

Propriedades de entrega personalizadas

As assinaturas de evento permitem que você configure cabeçalhos HTTP que estão incluídos nos eventos entregues. Essa funcionalidade permite que você defina cabeçalhos personalizados que são exigidos por um destino. Você pode configurar até dez cabeçalhos ao criar uma assinatura de evento. Cada valor de cabeçalho não deve ser maior que 4.096 (4K) bytes. Você pode definir os cabeçalhos personalizados nos eventos que são entregues aos seguintes destinos:

• Webhooks
• Hubs de eventos do Azure

Próximas etapas

• Entregar eventos aos pontos de extremidade do Webhook.