Visão geral do assinante

Este documento mostra uma visão geral de como as assinaturas funcionam no Cloud Pub/Sub. Para ver 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). Consulte Como reproduzir e descartar mensagens para conseguir mais informações sobre a configuração de retenção de mensagens.
  • Uma mensagem publicada antes da criação de uma assinatura normalmente não é entregue. Portanto, uma mensagem publicada em um tópico sem inscrição não pode ser recuperada.

Quando uma mensagem é enviada a um inscrito, ele precisa confirmar ou recusá-la. Uma mensagem é considerada pendente depois de ser enviada para entrega e antes da confirmação pelo inscrito. O Cloud Pub/Sub tentará repetidamente enviar qualquer mensagem que não tiver sido confirmada ou não estiver pendente. Um inscrito tem um limite de tempo configurável ou ackDeadline, para confirmar a mensagem. Quando o prazo terminar, uma mensagem pendente torna-se não confirmada.

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. Normalmente, para entregar mais de uma vez, o assinante precisa ser idempotente ao processar as mensagens. Execute uma vez o processamento de streams de mensagens do Cloud Pub/Sub usando o PubsubIO do Cloud Dataflow. O PubsubIO remove mensagens duplicadas com base em identificadores de mensagem personalizados ou naqueles 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, consulte Como configurar assinaturas.

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

Enviar comentários sobre…