Visão geral do assinante

Neste documento, mostramos uma visão geral de como as assinaturas funcionam no 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 assinatura nele. Somente mensagens publicadas no tópico após a criação da assinatura estarão disponíveis para aplicativos do assinante. A assinatura 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 assinaturas, mas cada assinatura 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 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 Pub/Sub tenta repetidamente entregar qualquer mensagem que não tenha sido confirmada. No entanto, enquanto houver alguma mensagem pendente para um assinante, o Pub/Sub 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 Pub/Sub tenta reenviá-la.

Geralmente, o Pub/Sub entrega cada mensagem uma vez e na ordem em que elas foram publicadas. 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. Você pode realizar exatamente uma vez o processamento de streams de mensagens do Pub/Sub usando Apache Beam programming model. Os conectores de E/S do Apache Beam permitem que você interaja com o Cloud Dataflow por meio de fontes e coletores controlados. Você pode usar o conector PubSubIO do Apache Beam (para Java e Python) para ler a partir do 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 editor do tópico ao qual você assinou 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 mensagens.

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

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

Assinatura de push

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

  1. O servidor do 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 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 as dependências do Google Cloud, como credenciais e biblioteca de cliente.

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

  Pull Push
Endpoints Qualquer dispositivo da Internet que tem credenciais autorizadas pode chamar a API Pub/Sub. Um servidor HTTPS com certificado não autoassinado acessível na Web pública. O endpoint de recebimento pode ser separado da assinatura do Pub/Sub, para que as mensagens de várias assinaturas sejam enviadas para um único endpoint.
Balanceamento de carga Vários assinantes podem fazer chamadas de pull para a mesma assinatura "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 no mesmo projeto que o assinante.
Para todos os outros endpoints do Console do Google Cloud, é necessário configurar (e verificar) os endpoints de push. Os endpoints precisam ser acessíveis via nomes DNS e ter certificados SSL instalados.
Controle de fluxo O cliente do assinante controla a taxa de entrega. O assinante pode modificar dinamicamente o prazo de confirmação, o que permite que o processamento da mensagem seja arbitrariamente longo. O servidor do Pub/Sub implementa automaticamente o controle de fluxo. Não há necessidade de 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 Pub/Sub detecte atividade do assinante, o relógio de exclusão de assinatura será reiniciado. Usando políticas de expiração de assinatura, é possível configurar a duração da inatividade ou tornar a assinatura persistente, independentemente da atividade. Também é possível excluir uma assinatura manualmente.

Embora seja possível criar uma nova assinatura com o mesmo nome de uma assinatura excluída, a nova assinatura não tem relação com a 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