Publicar cobertura

A alta latência de cauda ao publicar mensagens pode ser causada por atrasos de rede temporários ou lentidão temporária do lado do servidor. A publicação de cobertura permite que um cliente editor do Pub/Sub envie uma solicitação de publicação de backup (coberta) em paralelo se uma solicitação em andamento não for concluída dentro de um atraso configurado, usando qualquer resposta que retornar primeiro.

Neste documento, fornecemos informações sobre como usar o hedging de publicação com mensagens publicadas em um tópico.

Antes de começar

Antes de configurar o fluxo de trabalho de publicação, conclua as seguintes tarefas:

Funções exigidas

Para receber as permissões necessárias para enviar solicitações de publicação protegidas a um tópico, peça ao administrador para conceder a você o papel do IAM de Publicador do Pub/Sub (roles/pubsub.publisher) no tópico. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Você precisa de permissões adicionais para criar ou atualizar tópicos e assinaturas.

Sobre a cobertura de publicação

As configurações de cobertura controlam como e quando as bibliotecas de cliente do Pub/Sub enviam solicitações de publicação cobertas. A cobertura de publicação está desativada por padrão. Quando ativadas, as bibliotecas de cliente têm as seguintes configurações de hedging:

  • Atraso de hedge: o tempo que uma biblioteca de cliente espera antes de enviar uma solicitação de publicação adicional em paralelo se a solicitação anterior não tiver sido concluída. O valor padrão é 1 segundo, e o valor configurado precisa estar entre 100 milissegundos e 10 segundos.
  • Máximo de tokens: o número máximo de tokens que uma biblioteca de cliente pode acumular para enviar solicitações de publicação com hedge. Cada solicitação de publicação protegida consome um token. O valor padrão é 50, e o valor configurado precisa estar entre 1 e 250.
  • Proporção de reabastecimento: o número de tokens adicionados para cada solicitação de publicação bem-sucedida. Esse valor controla a fração máxima de solicitações de publicação que podem ser protegidas ao longo do tempo. Por exemplo, uma proporção de preenchimento de 0,1 permite que até 10% das solicitações de publicação sejam protegidas. O valor padrão é 0,1, e o valor configurado precisa estar entre 0,001 e 0,2.

Para solicitações de publicação de hedge, o atraso de hedge precisa ser menor que o tempo limite da solicitação inicial e o tempo limite total nas configurações de nova tentativa do editor. Caso contrário, o cliente do editor não será inicializado. Quando a cobertura de publicação está ativada, a biblioteca de cliente envia solicitações de publicação da seguinte maneira:

  • Se uma solicitação de publicação em andamento não for concluída dentro do atraso de hedge e pelo menos um token estiver disponível, a biblioteca de cliente consumirá um token e enviará uma solicitação de publicação adicional para o mesmo lote de mensagens em paralelo, mantendo a solicitação inicial pendente.
  • Se nenhuma das solicitações em andamento for concluída após outro atraso de hedge, a biblioteca de cliente vai continuar enviando outras solicitações de hedge em intervalos do atraso de hedge enquanto os tokens permanecerem disponíveis e o tempo limite total não expirar.
  • Assim que qualquer solicitação de publicação em andamento para o lote for bem-sucedida, a biblioteca de cliente concluirá a operação de publicação, cancelará as tentativas em andamento restantes para esse lote e aumentará os tokens disponíveis pela proporção de reabastecimento, até o máximo de tokens.

Proteger uma solicitação de publicação

Ao contrário das solicitações de repetição, que aguardam uma solicitação de publicação em andamento falhar ou expirar, a cobertura de publicação mantém a solicitação inicial pendente enquanto envia uma solicitação de cobertura simultânea. Isso reduz a latência de cauda sem cancelar prematuramente as solicitações que estão prestes a serem concluídas.

Como várias solicitações para o mesmo lote de mensagens podem estar em andamento simultaneamente, mais de uma tentativa pode ser bem-sucedida antes que as tentativas restantes sejam canceladas, já que o cancelamento da solicitação de publicação é feito com base no melhor esforço. Como resultado, você pode receber mensagens duplicadas com IDs diferentes, o que pode aumentar o tráfego de rede do cliente e os custos do Pub/Sub para publicar e entregar essas cópias. Consulte Resolver problemas de mensagens duplicadas, reenviadas ou ausentes para ver dicas sobre como lidar com mensagens duplicadas.

Se uma degradação do serviço causar um aumento sustentado na latência ou nos erros, as configurações de máximo de tokens e taxa de preenchimento vão impedir que as taxas de publicação protegidas fiquem muito altas. Como os tokens são adicionados apenas quando as solicitações de publicação são bem-sucedidas, a lentidão ou os erros sustentados esgotam rapidamente os tokens disponíveis e limitam automaticamente as solicitações de hedge.

Este exemplo de código demonstra a criação de um editor com configurações de hedging personalizadas. Nem todas as bibliotecas de cliente são compatíveis com a cobertura de publicação. Consulte a documentação de referência da API da linguagem escolhida.

Java

Antes de tentar essa amostra, siga as instruções de configuração do Java em Guia de início rápido: como usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API Pub/Sub para Java (em inglês). 


import com.google.api.core.ApiFuture;
import com.google.cloud.pubsub.v1.HedgingSettings;
import com.google.cloud.pubsub.v1.Publisher;
import com.google.protobuf.ByteString;
import com.google.pubsub.v1.PubsubMessage;
import com.google.pubsub.v1.TopicName;
import java.io.IOException;
import java.time.Duration;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;

public class PublishWithHedgingSettingsExample {
  public static void main(String... args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.
    String projectId = "your-project-id";
    String topicId = "your-topic-id";

    publishWithHedgingSettingsExample(projectId, topicId);
  }

  public static void publishWithHedgingSettingsExample(String projectId, String topicId)
      throws IOException, ExecutionException, InterruptedException {
    TopicName topicName = TopicName.of(projectId, topicId);
    Publisher publisher = null;

    try {
      // Hedging settings configures how and when the publisher sends multiple concurrent publish
      // requests to reduce tail latency.
      Duration hedgeDelay = Duration.ofMillis(500); // default: 1000 ms (1 second)
      int maxTokens = 100; // default: 50
      float refillRatio = 0.05f; // default: 0.1

      HedgingSettings hedgingSettings =
          HedgingSettings.newBuilder()
              .setHedgeDelay(hedgeDelay)
              .setMaxTokens(maxTokens)
              .setRefillRatio(refillRatio)
              .build();

      // Create a publisher instance with hedging settings bound to the topic
      publisher = Publisher.newBuilder(topicName).setHedgingSettings(hedgingSettings).build();

      String message = "Hello world!";
      ByteString data = ByteString.copyFromUtf8(message);
      PubsubMessage pubsubMessage = PubsubMessage.newBuilder().setData(data).build();

      // Once published, returns a server-assigned message id (unique within the topic)
      ApiFuture<String> messageIdFuture = publisher.publish(pubsubMessage);
      String messageId = messageIdFuture.get();
      System.out.println("Published a message with hedging settings: " + messageId);

    } finally {
      if (publisher != null) {
        // When finished with the publisher, shutdown to free up resources.
        publisher.shutdown();
        publisher.awaitTermination(1, TimeUnit.MINUTES);
      }
    }
  }
}

Publicar hedging com chaves de ordem

A cobertura de publicação não pode ser usada com a ordenação de mensagens. Como a cobertura de publicação envia solicitações de publicação simultâneas para o mesmo lote de mensagens, o serviço do Pub/Sub pode receber e processar essas solicitações fora de ordem. Se você ativar a ordenação de mensagens e a cobertura de publicação em um cliente do editor, a criação do editor vai falhar com um erro.

Dicas e práticas recomendadas

Considere as seguintes práticas recomendadas ao configurar o hedging de publicação:

  • Use a cobertura para latência de cauda transitória: a cobertura de publicação foi projetada para suavizar picos de latência de curta duração causados por atrasos temporários na rede ou lentidão breve do lado do servidor. Não use o hedging para mitigar interrupções prolongadas ou erros persistentes.
  • Hedging com políticas de repetição: defina um tempo limite de solicitação inicial maior nas configurações de repetição, além de um atraso de hedge menor. Tempos limite curtos e agressivos cancelam solicitações prematuramente e acionam novas tentativas completas, descartando o trabalho já em andamento no servidor. Um tempo limite maior permite que a solicitação original seja concluída se houver apenas um pequeno atraso.
  • Controle de fluxo e hedging do lado do cliente: o hedging de publicação não resolve atrasos do lado do cliente, como contenção de CPU ou falta de linhas de execução. Se a alta latência de publicação for causada pelo enfileiramento de mensagens na memória do cliente, o uso do controle de fluxo para gerenciar os tamanhos das filas pode ajudar, mas as restrições de recursos do host também precisam ser resolvidas.
  • Monitore as métricas de latência e capacidade de publicação: use gráficos de métricas do Monitoring, como topic/send_request_latencies, para identificar picos de latência de cauda e determinar se a cobertura pode ajudar. Altas taxas de erros CANCELLED podem indicar que os prazos de solicitação estão configurados como muito baixos. Quando ajustada de maneira eficaz, a cobertura de publicação mantém a capacidade de processamento de mensagens e o custo de bytes do tópico aproximadamente constantes, mesmo durante a latência de cauda de publicação.

A seguir

Para saber como configurar as opções avançadas de publicação, consulte: