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:
Como o Pub/Sub funciona e os diferentes termos do Pub/Sub.
Os diferentes tipos de subscrições que o Pub/Sub suporta e por que motivo pode querer usar uma subscrição push.
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.

Segue-se uma breve descrição do fluxo de trabalho que faz referência à Figura 3:
- 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. - 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. - 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:
A latência de rede de ida e volta entre os servidores do Pub/Sub e o ponto final de envio
O tempo de processamento do subscritor
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?
Crie uma subscrição push para o seu tópico.
Resolva um problema com uma subscrição push.
Crie ou modifique uma subscrição com a CLI gcloud.
Crie ou modifique uma subscrição com APIs REST.
Crie ou modifique uma subscrição com APIs RPC.