Vista geral do serviço Pub/Sub

O Pub/Sub é um serviço de publicação/subscrição (Pub/Sub), um serviço de mensagens em que os remetentes de mensagens estão separados dos destinatários de mensagens. Existem vários conceitos-chave num serviço Pub/Sub que são explicados com a ajuda da figura seguinte.

Seguem-se os componentes de um serviço Pub/Sub:

• Publicador (também denominado produtor): cria mensagens e envia-as (publica-as) para o serviço de mensagens num tópico especificado.

• Mensagem: os dados que se movem através do serviço.

• Tópico: uma entidade com nome que representa um feed de mensagens.

• Esquema: uma entidade com nome que rege o formato de dados de uma mensagem do Pub/Sub.

• Subscrição: uma entidade nomeada que representa um interesse em receber mensagens sobre um tópico específico.

• Subscritor (também denominado consumidor): recebe mensagens numa subscrição especificada.

O procedimento seguinte aborda o fluxo de trabalho do serviço Pub/Sub:

1. Duas aplicações de publicador, Publisher 1 e Publisher 2, enviam mensagens para um único tópico do Pub/Sub. O publicador 1 envia a mensagem A e o publicador 2 envia a mensagem B.

2. O tópico em si está associado a duas subscrições. Estas são a Subscrição 1 e a Subscrição 2.

3. O tópico também está associado a um esquema.

4. Cada subscrição recebe uma cópia das mensagens A e B do tópico.

5. A Subscrição 1 está associada a duas aplicações de subscrição: Subscritor 1 e Subscritor 2. As duas aplicações subscritoras recebem um subconjunto das mensagens do tópico. Neste exemplo, o subscritor 1 recebe a mensagem B, enquanto o subscritor 2 recebe a mensagem A do tópico.

6. A Subscrição 2 está apenas associada a uma única aplicação de subscrição denominada Subscritor 3. Assim, o subscritor 3 recebe todas as mensagens do tópico.

Ciclo de vida de uma mensagem

Suponha que um único cliente publicador está ligado a um tópico. O tópico tem uma única subscrição anexada. Um único subscritor está associado à subscrição.

Os passos seguintes descrevem como uma mensagem flui no Pub/Sub:

1. Uma aplicação de publicador envia uma mensagem para um tópico do Pub/Sub.

2. A mensagem é escrita no armazenamento.

3. Além de escrever a mensagem no armazenamento, o Pub/Sub envia a mensagem para todas as subscrições anexadas do tópico.

   Neste exemplo, é uma única subscrição.

4. A subscrição envia a mensagem para uma aplicação de subscrição anexada.

5. O subscritor envia uma confirmação ao Pub/Sub de que processou a mensagem.

   Depois de, pelo menos, um subscritor de cada subscrição acusar a receção da mensagem, o Pub/Sub elimina a mensagem do armazenamento.

Estado de uma mensagem no Pub/Sub

Enquanto uma mensagem estiver pendente para um subscritor, o Pub/Sub não tenta entregá-la a nenhum outro subscritor na mesma subscrição. O subscritor tem um período configurável e limitado, conhecido como ackDeadline, para acusar a receção da mensagem pendente. Após o prazo, a mensagem deixa de ser considerada pendente e fica novamente disponível para entrega.

Uma mensagem num serviço Pub/Sub pode ter três estados:

• Mensagens com confirmação de receção (acked). Depois de uma aplicação de subscritor processar uma mensagem enviada de um tópico para uma subscrição, envia uma confirmação de volta para o Pub/Sub. Se todas as subscrições num tópico tiverem confirmado a receção da mensagem, a mensagem é eliminada de forma assíncrona da origem da mensagem de publicação e do armazenamento.

• Mensagens não reconhecidas (unacked). Se o Pub/Sub não receber uma confirmação dentro do prazo de confirmação, uma mensagem pode ser entregue mais do que uma vez. Por exemplo, o subscritor pode enviar uma confirmação após o prazo expirar ou a confirmação pode ser perdida devido a problemas de rede temporários. Uma mensagem não confirmada continua a ser entregue até que a duração da retenção da mensagem expire desde que a mensagem foi publicada. Neste ponto, a mensagem expira.

• Mensagens com reconhecimento negativo (nacked). O envio de um NACK para uma mensagem por parte de um subscritor faz com que o Pub/Sub a reenvie imediatamente. Quando um subscritor envia um NACK para mensagens inválidas ou quando não consegue processar as mensagens, o subscritor ajuda a garantir que estas mensagens não são perdidas e que são processadas com êxito. Pode usar modifyAckDeadline com um valor de 0 para enviar um NACK a uma mensagem.

Escolha um padrão de publicação e subscrição do Pub/Sub

Quando existem vários clientes publicadores e subscritores do Pub/Sub, também tem de escolher o tipo de arquitetura de publicação e subscrição que quer configurar.

Alguns dos padrões de publicação/subscrição do Pub/Sub suportados incluem o seguinte:

• Fan in (muitos-para-um). Neste exemplo, várias aplicações de publicadores publicam mensagens num único tópico. Este tópico único está associado a uma única subscrição. A subscrição está, por sua vez, associada a uma única aplicação de subscrição que recebe todas as mensagens publicadas do tópico.

• Balanceamento de carga (muitos-para-muitos). Neste exemplo, uma ou várias aplicações de publicadores publicam mensagens num único tópico. Este único tópico está associado a uma única subscrição que, por sua vez, está ligada a várias aplicações de subscritores. Cada uma das aplicações subscritoras recebe um subconjunto das mensagens publicadas, e não existem duas aplicações subscritoras que recebam o mesmo subconjunto de mensagens. Neste caso de equilíbrio de carga, usa vários subscritores para processar mensagens em grande escala. Se precisar de suporte para mais mensagens, adicione mais subscritores para receber mensagens da mesma subscrição.

• Expandir (um-para-muitos). Neste exemplo, uma ou várias aplicações de publicadores publicam mensagens num único tópico. Este único tópico está associado a várias subscrições. Cada subscrição está associada a uma única aplicação de subscrição. Cada uma das aplicações subscritoras recebe o mesmo conjunto de mensagens publicadas do tópico. Quando um tópico tem várias subscrições, todas as mensagens têm de ser enviadas para um subscritor que recebe mensagens em nome de cada subscrição. Se precisar de realizar diferentes operações de dados no mesmo conjunto de mensagens, a distribuição é uma boa opção. Também pode anexar vários subscritores a cada subscrição e receber um subconjunto de mensagens com equilíbrio de carga para cada subscritor.

Escolha uma opção de configuração do Pub/Sub

Pode configurar um ambiente do Pub/Sub através de qualquer uma das seguintes opções:

• Trusted Cloud consola
• CLI do Google Cloud
• Bibliotecas cliente do Google Cloud (biblioteca cliente de nível elevado)
• APIs REST e RPC (biblioteca cliente de baixo nível)

A sua escolha de uma opção de configuração do Pub/Sub depende do seu exemplo de utilização.

Se for um utilizador novo da Trusted Cloud consola e quiser testar o Pub/Sub, use a consola ou a gcloud CLI.

A biblioteca de cliente de nível superior é recomendada para casos em que precisa de um elevado débito e uma baixa latência com custos de processamento e operacionais mínimos. Por predefinição, a biblioteca cliente de alto nível usa a API StreamingPull. As bibliotecas cliente de nível superior contêm funções e classes pré-criadas que processam as chamadas de API subjacentes para autenticação, otimização da taxa de transferência e da latência, formatação de mensagens e outras funcionalidades.

A biblioteca cliente de baixo nível é uma biblioteca gRPC gerada automaticamente e entra em ação quando usa as APIs de serviço diretamente.

• Para usar as bibliotecas cliente de nível elevado, consulte as bibliotecas cliente do Pub/Sub.

• Para usar diretamente as bibliotecas cliente geradas automaticamente de baixo nível, consulte a vista geral das APIs Pub/Sub.

Seguem-se algumas práticas recomendadas para usar as bibliotecas de cliente:

• Escolha o idioma da biblioteca de cliente certo. O desempenho das bibliotecas cliente do Pub/Sub varia consoante o idioma. Por exemplo, a biblioteca cliente Java é mais eficaz no aumento vertical do que a biblioteca cliente Python e pode processar mais débito. Java, C++ e Go são linguagens mais eficientes em termos de recursos de computação necessários para processar as cargas de publicação ou subscrição.

• Use a versão mais recente da biblioteca de cliente. As bibliotecas de cliente do Pub/Sub são atualizadas constantemente com novas funcionalidades e correções de erros. Certifique-se de que está a usar a versão mais recente da biblioteca de cliente para o seu idioma.

• Reutilize clientes publicadores. Ao publicar mensagens, é mais eficiente reutilizar o mesmo cliente publicador em vez de criar novos clientes publicadores para cada pedido de publicação. Isto deve-se ao facto de o primeiro pedido de publicação após a criação de um novo cliente publicador demorar algum tempo a estabelecer uma ligação autorizada. Em alguns idiomas, como o Node, que não têm um cliente de publicador explícito, reutilize o objeto no qual chama o método publish. Por exemplo, no Node, guarde e reutilize o objeto de tópico.

Como configurar o Pub/Sub

Seguem-se os passos de nível superior para configurar o Pub/Sub:

1. Crie ou escolha um Trusted Cloud projeto onde pode configurar o Pub/Sub.

2. Ative a API Pub/Sub.

3. Obtenha as funções e as autorizações necessárias para executar o Pub/Sub.

4. Crie um tópico.

5. Se a estrutura das mensagens for fundamental, defina um esquema para as suas mensagens.

6. Anexe o esquema ao tópico.

7. Configure um cliente publicador que possa publicar mensagens no tópico.

8. Se necessário, configure opções de publicação avançadas, como o controlo de fluxo, o envio de mensagens em lote e o controlo de concorrência.

9. Escolha um tipo de subscrição com base na forma como quer receber mensagens.

10. Crie uma subscrição para o tópico escolhido.

11. Configure um cliente subscritor que possa receber mensagens da subscrição.

12. Se necessário, configure opções avançadas de entrega de mensagens, como a entrega exatamente uma vez, a gestão de concessões, a entrega ordenada e o controlo de fluxo.

13. Comece a publicar mensagens do seu cliente publicador no tópico.

14. Em simultâneo, configure o cliente subscritor para receber e processar estas mensagens.

Diretrizes para dar um nome a um tópico, uma subscrição, um esquema ou uma captura instantânea

Um nome de recurso do Pub/Sub identifica exclusivamente um recurso do Pub/Sub, como um tópico, uma subscrição, um esquema ou uma captura instantânea. O nome do recurso tem de estar no seguinte formato:

projects/project-identifier/collection/ID

• project-identifier: tem de ser o ID ou o número do projeto, disponível na consola do Trusted Cloud . Por exemplo, my-cool-project é um ID do projeto. 123456789123 é um número de projeto.

• collection: tem de ser um dos seguintes valores: topics, subscriptions, schemas ou snapshots.

• ID: tem de estar em conformidade com as seguintes diretrizes:

  • Não começar pela string goog
  • Começar com uma letra
  • Ter entre 3 e 255 carateres
  • Contêm apenas os seguintes carateres: letras [A-Za-z], números [0-9], travessões -, sublinhados _, pontos finais ., tis ~, sinais de mais + e sinais de percentagem %

  Pode usar os carateres especiais na lista anterior nos nomes dos recursos sem codificação de URL. No entanto, tem de garantir que quaisquer outros carateres especiais são codificados ou descodificados corretamente quando os usa em URLs. Por exemplo, mi-tópico é um ID inválido. No entanto, mi-t%C3%B3pico é válido. Este formato é importante quando faz chamadas REST.

O que se segue?

• Para começar a configurar o Pub/Sub com a CLI gcloud, consulte o Início rápido: publique e receba mensagens no Pub/Sub através da CLI gcloud.

• Para começar a configurar o Pub/Sub com a Trusted Cloud consola, consulte o Início rápido: publique e receba mensagens no Pub/Sub com a Trusted Cloud consola.

• Para começar a configurar o Pub/Sub com as bibliotecas de cliente, consulte o Início rápido: publique e receba mensagens no Pub/Sub com a biblioteca de cliente.