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

O Pub/Sub é um serviço de publicação/assinatura (Pub/Sub), um serviço de mensagens em que os remetentes são dissociados dos destinatários. Um serviço do Pub/Sub tem vários conceitos essenciais, explicados com a ajuda da figura a seguir.

Figura mostrando diferentes componentes de um serviço do Pub/Sub e como eles se conectam.
Figura 1 Dois clientes editores enviam duas mensagens diferentes para um tópico comum do Pub/Sub.

Confira 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 as mensagens relacionadas a uma assinatura específica.

O procedimento a seguir discute o fluxo de trabalho do serviço do 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 está anexado a duas assinaturas. São elas Assinatura 1 e 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 está conectada a dois aplicativos de assinante, Assinante 1 e Assinante 2. Os dois aplicativos de assinante recebem um subconjunto das mensagens do tópico. Neste exemplo, o Assinante 1 recebe a mensagem B , enquanto o Assinante 2 recebe a mensagem A do tópico.

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

Vida útil de uma mensagem

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 de 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 a entrega a 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 ao menos um assinante de cada assinatura reconhecer a mensagem, o Pub/Sub excluirá a mensagem do armazenamento.

Status de uma mensagem no Pub/Sub

Enquanto houver alguma mensagem pendente para um assinante, o Pub/Sub não tenta 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 fica disponível para entrega novamente.

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

  • Mensagens confirmadas (acked). Depois que um aplicativo de 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 de um tópico confirmarem o recebimento da mensagem, ela será excluída de modo assíncrono da origem de mensagens publicadas e do armazenamento.

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

  • Mensagens confirmadas negativamente (nacked). A confirmação negativa de uma mensagem por um assinante faz com que o Pub/Sub a reentregue imediatamente com base nas configurações de nova tentativa padrão, que podem ser modificadas. Quando um assinante confirma negativamente mensagens inválidas ou quando não consegue processar as mensagens, ele ajuda a garantir que essas mensagens não sejam perdidas e que sejam processadas. É possível usar modifyAckDeadline com um valor de 0 para confirmar negativamente uma mensagem.

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

Quando há vários clientes editores e assinantes do Pub/Sub, também é necessário escolher o tipo de arquitetura de publicação e assinatura que você quer configurar.

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

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

  • Um único destino (muitos para um). Neste exemplo, vários aplicativos de editor 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.

  • Balanceamento de carga (muitos 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 uma única assinatura que, por sua vez, está conectada a vários aplicativos de assinante. Cada um dos aplicativos de assinante recebe um subconjunto das mensagens publicadas, e nenhum dos dois aplicativos 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 precisarem ser aceitas, adicione mais assinantes para receber mensagens da mesma assinatura.

  • Vários destinos (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 está conectada a um único aplicativo de assinante. Cada um dos aplicativos de assinante recebe o mesmo conjunto de mensagens publicadas do tópico. Quando um tópico tem várias assinaturas, cada mensagem precisa ser enviada a um assinante que recebe mensagens em nome de cada assinatura. Se você precisar realizar 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 receber 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 do Pub/Sub usando uma das seguintes opções:

  • Google Cloud Console do
  • Google Cloud CLI
  • 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 conhece o Google Cloud console e quer testar o Pub/Sub, use o console ou a gcloud CLI.

A biblioteca de cliente de alto nível é recomendada para casos em que você precisa de alta capacidade de processamento 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 pré-criadas que processam as chamadas de API subjacentes para autenticação, otimização de capacidade de processamento 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. A performance das bibliotecas de cliente do Pub/Sub varia de acordo com a linguagem. Por exemplo, a biblioteca de cliente Java é mais eficaz na escalonabilidade vertical do que a biblioteca de cliente Python e pode processar mais capacidade de processamento. 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 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. Confira se você está usando a versão mais recente da biblioteca de cliente para sua linguagem.

  • Reutilize clientes editores. Ao publicar mensagens, é mais eficiente reutilizar o mesmo cliente editor em vez de criar novos clientes editores 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 editor exige algum tempo para estabelecer uma conexão autorizada. Em algumas linguagens, como o Node, que não têm um cliente editor explícito, 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 etapas de nível superior para configurar o Pub/Sub:

  1. Crie ou escolha um Google Cloud projeto em que você possa configurar o Pub/Sub.

  2. Habilite a API Pub/Sub.

  3. Acesse 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 essencial, defina um esquema para suas mensagens.

  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 exatamente uma vez, gerenciamento de concessão, entrega ordenada e controle de fluxo.

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

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

Diretrizes para nomear um tópico, assinatura, esquema ou 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 ter o seguinte formato:

projects/project-identifier/collection/ID

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

  • collection: precisa ser um de 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], hifens -, sublinhados _, pontos ., acentos til ~, sinais de mais +, e sinais de porcentagem %

    É possível usar os caracteres especiais na lista anterior em nomes de recursos sem codificação para URLs. No entanto, é preciso garantir que os demais 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 ao fazer chamadas REST.

A seguir