Subscrições de emissão

Este documento fornece uma vista geral de uma subscrição push, do respetivo fluxo de trabalho e das propriedades associadas.

Na entrega push, o Pub/Sub inicia pedidos à sua aplicação de subscrição para entregar mensagens. As mensagens são entregues a um servidor endereçável publicamente ou a um webhook, como um pedido HTTPS POST.

As subscrições push minimizam as dependências de bibliotecas cliente específicas do Pub/Sub e os mecanismos de autenticação. Também funcionam bem com tecnologias de serviços sem servidor e de dimensionamento automático, como as funções do Cloud Run, o Cloud Run e o Google Kubernetes Engine.

Antes de começar

Antes de ler este documento, certifique-se de que conhece o seguinte:

Fluxo de trabalho de subscrição de emissão

Numa subscrição push, um servidor do Pub/Sub inicia um pedido ao cliente subscritor para entregar mensagens.

A imagem seguinte mostra o fluxo de trabalho entre um cliente subscritor e uma subscrição push.

Fluxo de mensagens para uma subscrição push
Figura 3. Fluxo de trabalho para uma subscrição push

Segue-se uma breve descrição do fluxo de trabalho que faz referência à Figura 3:

  1. O servidor Pub/Sub envia cada mensagem como um pedido HTTPS para o cliente subscritor num ponto final pré-configurado. Esta solicitação é apresentada como PushRequest na imagem.
  2. O ponto final confirma a mensagem devolvendo um código de estado HTTP de êxito. Uma resposta sem êxito indica que o Pub/Sub tem de reenviar as mensagens. Esta resposta é apresentada como um PushResponse na imagem.
  3. O Pub/Sub ajusta dinamicamente a taxa de pedidos push com base na taxa à qual recebe respostas de sucesso.

Propriedades de uma subscrição push

As propriedades que configurar para uma subscrição push determinam a forma como escreve mensagens para a sua subscrição. Para mais informações, consulte o artigo Propriedades da subscrição.

Como os pontos finais de envio recebem mensagens

Quando o Pub/Sub envia uma mensagem para um ponto final de envio, pode optar por enviá-la envolvida ou não envolvida. Por predefinição, as mensagens são enviadas com quebra de linha.

  • Wrapped. O Pub/Sub envia a mensagem no corpo JSON de um pedido POST.
  • Desembrulhado. O Pub/Sub envia os dados da mensagem não processados diretamente como o corpo HTTP.

Os exemplos seguintes mostram um corpo envolvido de um pedido JSON POST a um ponto final de envio que contém a string Hello there no campo message.data

O corpo de um pedido POST é um objeto JSON. Os dados da mensagem estão no campo message.data e estão codificados em Base64.

Exemplo de um pedido com os valores mínimos

  {
      "message": {
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
  }

Exemplo de um pedido com os valores máximos

Tenha em atenção que este exemplo mostra os valores máximos atuais, que podem mudar ao longo do tempo. Além disso, o mapa de atributos pode conter uma variedade de valores.

  {
      "deliveryAttempt": 5,
      "message": {
          "attributes": {
              "key": "value"
          },
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "orderingKey": "key",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
}

Para receber mensagens de subscrições push, use um webhook e processe os POST pedidos que o Pub/Sub envia para o ponto final push. Para mais informações sobre o processamento destes pedidos POST no App Engine, consulte o artigo Escrever e responder a mensagens do Pub/Sub.

Depois de receber um pedido push, devolva um código de estado HTTP. Para acusar a receção da mensagem, devolva um dos seguintes códigos de estado:

  • 102
  • 200
  • 201
  • 202
  • 204

Para enviar uma confirmação negativa da mensagem, devolva qualquer outro código de estado. Se enviar uma confirmação negativa ou o prazo de confirmação expirar, o Pub/Sub reenvia a mensagem. Não pode modificar o prazo de confirmação de mensagens individuais que recebe de subscrições push.

Autenticação para subscrições push

Se uma subscrição push usar autenticação, o serviço Pub/Sub assina um JWT e envia o JWT no cabeçalho de autorização do pedido push.

Para mais informações sobre a configuração da autenticação, consulte o artigo Autentique pedidos push.

Parar e retomar o envio de mensagens

Para impedir temporariamente que o Pub/Sub envie pedidos para o ponto final de envio, altere a subscrição para extração. A mudança pode demorar vários minutos a entrar em vigor.

Para retomar o envio push, defina novamente o URL para um ponto final válido. Para interromper permanentemente a entrega, elimine a subscrição.

Retirada de envio

Se um subscritor de push enviar demasiados reconhecimentos negativos, o Pub/Sub pode começar a entregar mensagens através de um recuo de push. Quando o Pub/Sub usa um recuo de envio, deixa de entregar mensagens durante um período predeterminado. Este intervalo de tempo pode variar entre 100 milissegundos e 60 segundos. Após o tempo decorrido, o Pub/Sub começa a enviar mensagens novamente.

A recusa exponencial usa um algoritmo de recusa exponencial para determinar o atraso que o Pub/Sub usa entre o envio de mensagens. Este período é calculado com base no número de confirmações negativas que os subscritores de push enviam.

Por exemplo, se um subscritor de envio receber cinco mensagens por segundo e enviar um reconhecimento negativo por segundo, o Pub/Sub envia mensagens aproximadamente a cada 500 milissegundos. Em alternativa, se o subscritor de push enviar cinco reconhecimentos negativos por segundo, o Pub/Sub entrega mensagens a cada 30 a 60 segundos.

Tenha em atenção as seguintes considerações sobre a repetição com recuo:

  • Não é possível ativar nem desativar a recusa de envio. Também não pode modificar os valores usados para calcular o atraso.
  • Acionadores de recuo nas seguintes ações:
    • Quando é recebido um reconhecimento negativo.
    • Quando o prazo de confirmação de uma mensagem expira.
  • A repetição com recuo aplica-se a todas as mensagens numa subscrição (global).

Taxa de fornecimento

O Pub/Sub ajusta o número de pedidos push simultâneos através de um algoritmo de início lento. O número máximo permitido de pedidos push simultâneos é a janela de push. O período de envio aumenta em qualquer entrega bem-sucedida e diminui em qualquer falha. O sistema começa com um tamanho da janela de um único dígito pequeno.

Quando um subscritor confirma as mensagens, o período aumenta exponencialmente. Para subscrições em que os subscritores confirmam mais de 99% das mensagens e têm uma latência média de pedidos push inferior a um segundo, a janela push deve expandir-se o suficiente para acompanhar qualquer débito de publicação.

A latência do pedido de envio inclui o seguinte:

Após 3000 mensagens pendentes por região, a janela aumenta linearmente para impedir que o ponto final de envio receba demasiadas mensagens. Se a latência média exceder um segundo ou o subscritor acusar a receção de menos de 99% dos pedidos, a janela diminui para o limite inferior de 3000 mensagens pendentes.

Para mais informações sobre as métricas que pode usar para monitorizar a entrega push, consulte o artigo Monitorizar subscrições push.

Quotas e limites

As subscrições push estão sujeitas a um conjunto de quotas e limites de recursos.

O que se segue?