Visão geral do serviço do Pub/Sub

O Pub/Sub é um publish/subscribe de publish/subscribe (publish/subscribe), um serviço de mensagens em que os remetentes são separados dos destinatários das mensagens. Um serviço Pub/Sub tem vários conceitos importantes, que são explicados com a ajuda da figura a seguir.

Figura que mostra diferentes componentes de um serviço Pub/Sub e como eles se conectam entre si.
Figura 1: dois clientes editores enviam duas mensagens diferentes para um tópico comum do Pub/Sub.

A seguir estão os componentes de um serviço do Pub/Sub:

  • Editor (também chamado de produtor): cria mensagens e as envia (publica) para o serviço de mensagens em um tópico específico.

  • Mensagem: os dados transferidos por meio do serviço.

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

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

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

  • Assinante (também chamado de consumidor): recebe mensagens sobre uma assinatura específica.

O procedimento a seguir discute o fluxo de trabalho do serviço Pub/Sub:

  1. Dois aplicativos de editor, editor 1 e editor 2, enviam mensagens para um único tópico do Pub/Sub. O editor 1 envia a mensagem A, e o editor 2 envia a mensagem B.

  2. O tópico em si é anexado a duas assinaturas. São a Assinatura 1 e a Assinatura 2.

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

  4. Cada assinatura recebe uma cópia das mensagens A e B do tópico.

  5. A assinatura 1 é conectada a dois aplicativos de assinante, o assinante 1 e o assinante 2. Os dois aplicativos de assinante recebem um subconjunto das mensagens do tópico. Neste exemplo, o assinante 1 recebe a mensagem B, e o assinante 2 recebe a mensagem A do tópico.

  6. A assinatura 2 está conectada apenas a um único aplicativo de assinante, chamado Assinante 3. Assim, o assinante 3 recebe todas as mensagens do tópico.

Ciclo de vida de uma mensagem no Pub/Sub

Suponha que um único cliente editor esteja conectado a um tópico. O tópico tem uma única assinatura anexada a ele. Um único assinante está conectado à assinatura.

Figura mostrando como uma mensagem flui no Pub/Sub.
Figura 2 Uma mensagem flui de um cliente editor para um cliente assinante pelo Pub/Sub.

As etapas a seguir descrevem como uma mensagem flui no Pub/Sub:

  1. Um aplicativo do editor envia uma mensagem para um tópico do Pub/Sub.

  2. A mensagem é gravada no armazenamento.

  3. Além de gravar a mensagem no armazenamento, o Pub/Sub entrega a mensagem para todas as assinaturas anexadas do tópico.

    Neste exemplo, é uma única assinatura.

  4. A assinatura envia a mensagem para um aplicativo de assinante anexado.

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

    Depois que pelo menos um assinante de cada assinatura confirmar a mensagem, o Pub/Sub a exclui do armazenamento.

Status de uma mensagem no Pub/Sub

Enquanto uma mensagem está pendente para o 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 configurável, conhecido como ackDeadline, para confirmar a mensagem pendente. Depois que o prazo termina, a mensagem não é mais considerada pendente, e o Pub/Sub tenta reenviá-la.

Uma mensagem em um serviço do Pub/Sub pode ter três estados:

  • Mensagens reconhecidas (confirmadas). Depois que o aplicativo do assinante processa uma mensagem enviada de um tópico para uma assinatura, ele envia uma confirmação de volta ao Pub/Sub. Se todas as assinaturas em um tópico confirmarem a mensagem, ela será excluída de maneira assíncrona da origem da mensagem publicada e do armazenamento.

  • Mensagens não confirmadas (não confirmadas). Se o Pub/Sub não receber uma confirmação dentro do prazo de confirmação, uma mensagem poderá ser entregue mais de uma vez. Por exemplo, o assinante pode enviar uma confirmação depois que o prazo expirar ou que a confirmação pode ser perdida devido a problemas temporários de rede. Uma mensagem não confirmada continuou sendo entregue até que a duração da retenção da mensagem expire após a publicação. Nesse momento, a mensagem expira.

  • Mensagens confirmadas negativamente (nacks). O reconhecimento de uma mensagem por um assinante faz com que o Pub/Sub a reenvie imediatamente. Quando um assinante envia mensagens inválidas ou não consegue processá-las, o assinante ajuda a garantir que essas mensagens não sejam perdidas e que, por fim, sejam processadas com sucesso. É possível usar modifyAckDeadline com um valor de 0 para atualizar uma mensagem.

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

Quando há vários clientes de editor e assinante, você também precisa escolher o tipo de arquitetura de publicação e assinatura que quer configurar.

Figura mostrando diferentes padrões de publicação e assinatura.
Figura 3 As relações entre editor e assinante podem ser de muitos para um (fan-in), de muitos para muitos (com balanceamento de carga) e de um para muitos (fan-out).

Alguns dos padrões de assinatura de publicação do Pub/Sub compatíveis incluem os seguintes:

  • Fan-in (muitos para um). Neste exemplo, vários aplicativos de editores publicam mensagens em um único tópico. Esse único tópico está anexado a uma única assinatura. A assinatura, por sua vez, está conectada a um único aplicativo de assinante que recebe todas as mensagens publicadas do tópico.

  • Carga balanceada (muitos para muitos). Neste exemplo, um ou vários aplicativos de editor publicam mensagens em um único tópico. Esse único tópico é anexado a uma única assinatura, que, por sua vez, está conectada a vários aplicativos de assinantes. Cada um dos aplicativos do assinante recebe um subconjunto das mensagens publicadas, e nenhum aplicativo de assinante recebe o mesmo subconjunto de mensagens. Nesse caso de balanceamento de carga, você usa vários assinantes para processar mensagens em escala. Se mais mensagens precisam ser compatíveis, você adiciona mais assinantes para receber mensagens da mesma assinatura.

  • Fan out (um para muitos). Neste exemplo, um ou vários aplicativos de editor publicam mensagens em um único tópico. Esse único tópico está anexado a várias assinaturas. Cada assinatura é conectada a um único aplicativo de assinante. Cada um dos aplicativos do assinante recebe o mesmo conjunto de mensagens publicadas do tópico. Quando um tópico tem várias assinaturas, cada mensagem precisa ser enviada para um assinante que as recebe em nome de cada assinatura. Caso você precise executar diferentes operações de dados no mesmo conjunto de mensagens, o fan-out é uma boa opção. Também é possível anexar vários assinantes a cada assinatura e conseguir um subconjunto de mensagens com balanceamento de carga para cada assinante.

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

É possível configurar um ambiente Pub/Sub usando qualquer uma das seguintes opções:

  • Console do Google Cloud
  • CLI do Google Cloud
  • Bibliotecas de cliente do Cloud (biblioteca de cliente de alto nível)
  • APIs REST e RPC (biblioteca de cliente de baixo nível)

A escolha de uma opção de configuração do Pub/Sub depende do seu caso de uso.

Se você não tem experiência com o console do Google Cloud e quer testar o Pub/Sub, use o console ou o gcloud CLI.

A biblioteca de cliente de alto nível é recomendada para casos em que você precisa de alta capacidade e baixa latência com sobrecarga operacional e custo de processamento mínimos. Por padrão, a biblioteca de cliente de alto nível usa a API StreamingPull. As bibliotecas de cliente de alto nível contêm funções e classes predefinidas que lidam com as chamadas de API subjacentes para autenticação, otimização da capacidade e latência, formatação de mensagens e outros recursos.

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

Confira algumas práticas recomendadas para usar as bibliotecas de cliente:

  • Escolha a linguagem certa da biblioteca de cliente. O desempenho das bibliotecas de cliente do Pub/Sub varia de acordo com a linguagem. Por exemplo, a biblioteca de cliente Java é mais eficaz no escalonamento vertical do que a biblioteca de cliente Python e pode lidar com mais capacidade. Java, C++ e Go são linguagens mais eficientes em termos de recursos de computação necessários para lidar com os carregamentos de publicação ou assinatura.

  • Use a versão mais recente da biblioteca de cliente. As bibliotecas de cliente do Pub/Sub são constantemente atualizadas com novos recursos e correções de bugs. Verifique se você está usando a versão mais recente da biblioteca de cliente para sua linguagem.

  • Reutilize clientes de editores. Ao publicar mensagens, é mais eficiente reutilizar o mesmo cliente de editor em vez de criar novos clientes de editor para cada solicitação de publicação. Isso ocorre porque a primeira solicitação de publicação após a criação de um novo cliente de editor leva algum tempo para estabelecer uma conexão autorizada. Em algumas linguagens, como o Node, que não têm um cliente explícito do editor, reutilize o objeto em que você chama o método de publicação. Por exemplo, no Node, salve e reutilize o objeto de tópico.

Como configurar o Pub/Sub

Confira as principais etapas para configurar o Pub/Sub:

  1. Crie ou escolha um projeto do Google Cloud para configurar o Pub/Sub.

  2. Ative a API Pub/Sub.

  3. Consiga as permissões e os papéis necessários para executar o Pub/Sub.

  4. Crie um tópico.

  5. Se a estrutura da mensagem for crítica, defina um esquema para elas.

  6. Anexe o esquema ao tópico.

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

  8. Se necessário, configure opções avançadas de publicação, como controle de fluxo, mensagens em lote e controle de simultaneidade.

  9. Escolha um tipo de assinatura com base em como você quer receber mensagens.

  10. Crie uma assinatura para o tópico escolhido.

  11. Configure um cliente assinante que possa receber mensagens da assinatura.

  12. Se necessário, configure opções avançadas de entrega de mensagens, como entrega única, gerenciamento de locação, entrega ordenada e controle de fluxo.

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

  14. Ao mesmo tempo, configure seu cliente assinante para receber e processar essas mensagens.

Diretrizes para nomear um tópico, uma assinatura, um esquema ou um snapshot

Um nome de recurso do Pub/Sub identifica exclusivamente um recurso do Pub/Sub, como um tópico, assinatura, esquema ou snapshot. O nome do recurso precisa estar no seguinte formato:

projects/project-identifier/collection/ID

  • project-identifier: precisa ser o ID ou número do projeto, disponível no console do Google Cloud. Por exemplo, my-cool-project é um ID do projeto. 123456789123 é o número do projeto.

  • collection: precisa ser topics, subscriptions, schemas ou snapshots.

  • ID: precisa estar em conformidade com as seguintes diretrizes:

    • Não começar com a string goog
    • Começar com uma letra
    • conter entre 3 e 255 caracteres;
    • Conter apenas os seguintes caracteres: letras [A-Za-z], números [0-9], traços -, sublinhados _, pontos ., tis ~, sinais de adição + e sinais de porcentagem %

    É possível usar os caracteres especiais da lista anterior em nomes de recursos sem codificação para URL. No entanto, é preciso garantir que todos os outros caracteres especiais sejam codificados ou decodificados corretamente quando usados em URLs. Por exemplo, mi-tópico é um ID inválido. No entanto, mi-t%C3%B3pico é válido. Esse formato é importante quando você faz chamadas REST.

A seguir