Visão geral do assinante

Este documento mostra uma visão geral de como as assinaturas funcionam no Cloud Pub/Sub. Para mais detalhes sobre assinaturas de entrega por pull e push, consulte o guia do assinante de pull e o guia do assinante de push.

Para receber as mensagens publicadas em um tópico, você precisa criar uma inscrição nele. Somente mensagens publicadas no tópico após a criação da inscrição ficam disponíveis em aplicativos de inscritos. A inscrição conecta o tópico a um aplicativo do inscrito, que recebe e processa as mensagens publicadas no tópico. Um tópico pode ter várias inscrições, mas cada inscrição pertence a somente um tópico.

Para saber mais sobre a criação e a atualização de assinaturas, consulte Como gerenciar tópicos e assinaturas.

Entrega pelo menos uma vez

O Cloud Pub/Sub entrega cada mensagem publicada pelo menos uma vez para cada assinatura. Há algumas exceções a esse comportamento:

  • Por padrão, uma mensagem que não possa ser entregue dentro do tempo máximo de retenção de sete dias é excluída e não fica mais acessível. Isso geralmente ocorre quando os assinantes não acompanham o fluxo das mensagens. É possível configurar a duração da retenção de mensagens (o intervalo é de dez minutos a sete dias). Veja Como reproduzir e descartar mensagens para mais informações sobre a configuração de retenção de mensagens.
  • Uma mensagem publicada antes de uma assinatura ser criada geralmente não será entregue para essa assinatura. Assim, uma mensagem publicada em um tópico que não tenha assinatura não será entregue a nenhum assinante.

Depois que uma mensagem é enviada ao assinante, ele precisa confirmá-la. Ela é considerada pendente após ser enviada para a entrega e antes da confirmação do assinante. O Cloud Pub/Sub tenta repetidamente entregar qualquer mensagem que não tenha sido confirmada. No entanto, ele tenta não entregá-la a nenhum outro assinante na mesma assinatura. O assinante tem um período de tempo limitado para confirmar a mensagem, que pode ser configurado e é chamado de ackDeadline. Depois que o prazo termina, a mensagem não é mais considerada pendente, e o Cloud Pub/Sub tenta reenviá-la.

Normalmente, o Cloud Pub/Sub entrega cada mensagem uma vez e na ordem em que foi publicada. No entanto, às vezes as mensagens podem ser entregues fora de ordem ou mais de uma vez. Em geral, acomodar mais de uma entrega requer que o assinante seja idempotente ao processar as mensagens. É possível estabelecer o processamento único dos fluxos de mensagens do Cloud Pub/Sub usando o Cloud Dataflow PubsubIO. O PubsubIO elimina as mensagens duplicadas com base em identificadores personalizados ou atribuídos pelo Cloud Pub/Sub. Também é possível ordenar o processamento com o Cloud Dataflow, usando as APIs de classificação padrão do serviço. Para alcançar a ordem, o inscrito do tópico ao qual você se inscreveu também pode incluir um token de sequência na mensagem. Consulte Ordem das mensagens para mais informações.

Entrega de pull ou push

Uma assinatura pode usar o mecanismo de pull ou push para a entrega de mensagens. É possível alterar ou configurar esse mecanismo a qualquer momento.

Assinatura de pull

Na entrega de pull, o aplicativo do seu assinante inicia solicitações para o servidor do Pub/Sub para recuperar as mensagens.

  1. O aplicativo assinante chama explicitamente o método pull, que solicita as mensagens para entrega.
  2. O servidor do Cloud Pub/Sub responde com a mensagem ou com um erro se a fila está vazia e um código de confirmação.
  3. O assinante chama explicitamente o método de confirmação com o código retornado para confirmar o recebimento.

Fluxo da solicitação de mensagem de assinatura de pull

Assinatura de push

Na entrega por push, o Cloud Pub/Sub inicia solicitações ao aplicativo do assinante para enviar mensagens.

  1. O servidor do Cloud Pub/Sub envia cada mensagem como uma solicitação HTTPS para o aplicativo do assinante em um endpoint pré-configurado.
  2. O endpoint confirma a mensagem com um código de status de sucesso HTTP. Uma resposta sem sucesso indica que a mensagem precisa ser reenviada.

Fluxo da solicitação de mensagem de assinatura de push

O Cloud Pub/Sub ajusta dinamicamente a taxa de solicitações de push com base na frequência em que recebe respostas bem-sucedidas.

A tabela a seguir oferece uma orientação para escolher o mecanismo de entrega adequado para seu aplicativo:

Pull Push
  • Grande volume de mensagens (muito mais do que uma por segundo).
  • A eficiência e a capacidade do processamento da mensagem são fundamentais.
  • Não é viável configurar um ponto de extremidade HTTPS público com um certificado SSL não autoassinado.
  • Diversos tópicos precisam ser processados pelo mesmo webhook.
  • Assinantes do Cloud Functions e do ambiente padrão do Google App Engine.
  • Ambientes em que não é viável configurar dependências do Google Cloud Platform, como credenciais e a biblioteca de cliente.

A tabela a seguir compara o envio por pull e push:

  Pull Push
Pontos de extremidade Qualquer dispositivo da Internet que tem credenciais autorizadas pode chamar a Cloud Pub/Sub API. Um servidor HTTPS com certificado não autoassinado acessível na Web pública. O ponto de extremidade de recebimento pode ser separado da inscrição do Cloud Pub/Sub, para que as mensagens de várias inscrições sejam enviadas para um único ponto de extremidade.
Balanceamento de carga Vários inscritos podem fazer chamadas de pull para a mesma inscrição "compartilhada". Cada inscrito receberá um subconjunto das mensagens. O ponto de extremidade de push pode ser um balanceador de carga.
Configuração Não é necessário configurar. Não é necessário configurar aplicativos do App Engine que estejam no mesmo projeto que o inscrito.
A configuração (e verificação) de pontos de extremidade de push é necessária no Console do Google Cloud Platform para todos os outros pontos de extremidade. Os pontos de extremidade precisam ser acessíveis via nomes de DNS e ter certificados SSL instalados.
Controle de fluxo O cliente do inscrito controla a taxa de entrega. O inscrito pode modificar dinamicamente o prazo de confirmação, o que permite que o processamento da mensagem seja arbitrariamente longo. O servidor do Cloud Pub/Sub implementa automaticamente o controle de fluxo. Não é necessário manipular o fluxo de mensagens no lado do cliente. No entanto, é possível indicar que o cliente não pode processar a carga de mensagens atual com a transmissão de um erro de HTTP.
Eficiência e capacidade Consegue alta capacidade com baixo uso de CPU e largura de banda. Para isso, permite a entrega e a confirmação de mensagens em lote, assim como o consumo paralelo massivo. Pode não ser eficaz se a pesquisa agressiva for usada para minimizar o tempo de entrega da mensagem. Entrega uma mensagem por solicitação e limita o número máximo de mensagens pendentes.

Ciclo de vida de uma assinatura

Por padrão, as assinaturas expiram após 31 dias de inatividade (por exemplo, se não houver conexões ativas, solicitações de pull ou sucessos de push). Caso o Cloud Pub/Sub detecte atividade do assinante, o relógio de exclusão de assinatura será reiniciado. Usando políticas de expiração de assinatura (na versão Beta), é possível configurar a duração da inatividade ou tornar a assinatura persistente, independentemente da atividade. Também é possível excluir uma assinatura manualmente.

É possível criar uma nova assinatura com o mesmo nome de uma excluída, mas ela não tem relação com a assinatura antiga. Mesmo que a assinatura excluída tivesse um grande número de mensagens não confirmadas, uma nova assinatura com nome idêntico não teria nenhum backlog (ou seja, nenhuma mensagem aguardando entrega) no momento da sua criação.

Para mais informações sobre como trabalhar com assinaturas, acesse Como configurar assinaturas.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…