Pubblica copertura

La latenza di coda elevata durante la pubblicazione dei messaggi può essere causata da ritardi di rete temporanei o da una lentezza temporanea lato server. La pubblicazione con hedging consente a un client publisher Pub/Sub di inviare in parallelo una richiesta di pubblicazione di backup (con hedging) se una richiesta in corso non viene completata entro un ritardo configurato, utilizzando la risposta che viene restituita per prima.

Questo documento fornisce informazioni sull'utilizzo della mitigazione della pubblicazione con i messaggi pubblicati in un argomento.

Prima di iniziare

Prima di configurare il workflow di pubblicazione, assicurati di aver completato le seguenti attività:

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per inviare richieste di pubblicazione con hedging a un argomento, chiedi all'amministratore di concederti il ruolo IAM Pub/Sub Publisher (roles/pubsub.publisher) nell'argomento. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Devi disporre di autorizzazioni aggiuntive per creare o aggiornare argomenti e sottoscrizioni.

Informazioni sulla copertura della pubblicazione

Le impostazioni di hedging controllano come e quando le librerie client Pub/Sub inviano richieste di pubblicazione con hedging. La copertura della pubblicazione è disattivata per impostazione predefinita. Se abilitate, le librerie client hanno le seguenti impostazioni di hedging:

  • Ritardo di hedge: il periodo di tempo che una libreria client attende prima di inviare una richiesta di pubblicazione aggiuntiva in parallelo se la richiesta precedente non è stata completata. Il valore predefinito è 1 secondo e il valore configurato deve essere compreso tra 100 millisecondi e 10 secondi.
  • Numero massimo di token: il numero massimo di token che una libreria client può accumulare per l'invio di richieste di pubblicazione con copertura. Ogni richiesta di pubblicazione con copertura consuma 1 token. Il valore predefinito è 50 e il valore configurato deve essere compreso tra 1 e 250.
  • Frequenza di ricarica: il numero di token aggiunti per ogni richiesta di pubblicazione andata a buon fine. Questo valore controlla la frazione massima di richieste di pubblicazione che possono essere sottoposte a hedging nel tempo. Ad esempio, un rapporto di ricarica di 0,1 consente di coprire fino al 10% delle richieste di pubblicazione. Il valore predefinito è 0,1 e il valore configurato deve essere compreso tra 0,001 e 0,2.

Per proteggere le richieste di pubblicazione, il ritardo di protezione deve essere inferiore sia al timeout della richiesta iniziale sia al timeout totale nelle impostazioni dei nuovi tentativi del publisher. In caso contrario, l'inizializzazione del client publisher non andrà a buon fine. Quando la limitazione della pubblicazione è abilitata, la libreria client invia le richieste di pubblicazione nel seguente modo:

  • Se una richiesta di pubblicazione in corso non viene completata entro il ritardo di protezione e è disponibile almeno un token, la libreria client consuma un token e invia una richiesta di pubblicazione aggiuntiva per lo stesso gruppo di messaggi in parallelo, mantenendo in sospeso la richiesta iniziale.
  • Se nessuna delle richieste in corso viene completata dopo un altro ritardo di hedging, la libreria client continua a inviare richieste con hedging aggiuntive a intervalli del ritardo di hedging, mentre i token rimangono disponibili e il timeout totale non è scaduto.
  • Non appena una richiesta di pubblicazione in corso per il batch ha esito positivo, la libreria client completa l'operazione di pubblicazione, annulla tutti i tentativi in corso rimanenti per quel batch e aumenta i token disponibili in base al rapporto di ricarica, fino al numero massimo di token.

Copertura di una richiesta di pubblicazione

A differenza delle richieste di nuovo tentativo, che attendono che una richiesta di pubblicazione in corso non vada a buon fine o scada, l'hedging della pubblicazione mantiene in sospeso la richiesta iniziale mentre invia una richiesta di hedging simultanea. In questo modo, si riduce la latenza di coda senza annullare prematuramente le richieste che stanno per essere completate.

Poiché più richieste per lo stesso gruppo di messaggi possono essere in corso contemporaneamente, più di un tentativo potrebbe riuscire prima che i tentativi rimanenti vengano annullati, in quanto l'annullamento della richiesta di pubblicazione è best-effort. Di conseguenza, potresti ricevere messaggi duplicati con ID messaggio diversi, il che può aumentare il traffico di rete del client e i costi di Pub/Sub per la pubblicazione e la consegna di questi duplicati. Consulta "Risolvi i problemi relativi ai messaggi duplicati, inviati di nuovo o mancanti" per suggerimenti sulla gestione dei messaggi duplicati.

Se un peggioramento del servizio causa un aumento prolungato della latenza o degli errori, le impostazioni relative al numero massimo di token e al tasso di ricarica impediscono che le frequenze di pubblicazione con copertura diventino troppo elevate. Poiché i token vengono aggiunti solo quando le richieste di pubblicazione vanno a buon fine, la lentezza o gli errori prolungati esauriscono rapidamente i token disponibili e limitano automaticamente le richieste con copertura.

Questo codice campione mostra come creare un publisher con impostazioni di copertura personalizzate. Non tutte le librerie client supportano l'hedging della pubblicazione; consulta la documentazione di riferimento dell'API per il linguaggio scelto.

Java

Prima di provare questo esempio, segui le istruzioni di configurazione di Java in Guida rapida: utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API Java di Pub/Sub. 


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);
      }
    }
  }
}

Copertura della pubblicazione con chiavi di ordinamento

La pubblicazione con hedging non può essere utilizzata con l'ordinamento dei messaggi. Poiché l'hedging della pubblicazione invia richieste di pubblicazione simultanee per lo stesso gruppo di messaggi, il servizio Pub/Sub potrebbe ricevere ed elaborare queste richieste non in ordine. Se abiliti sia l'ordinamento dei messaggi sia l'hedging della pubblicazione su un client publisher, la creazione del publisher non va a buon fine e viene generato un errore.

Suggerimenti e best practice

Quando configuri la copertura della pubblicazione, tieni presente le seguenti best practice:

  • Utilizza l'hedging per la latenza di coda temporanea: l'hedging della pubblicazione è progettato per attenuare i picchi di latenza di breve durata causati da ritardi di rete temporanei o da una breve lentezza lato server. Non fare affidamento sull'hedging per mitigare interruzioni prolungate o errori persistenti.
  • Hedging con policy di ripetizione: imposta un timeout della richiesta iniziale più lungo nelle impostazioni di ripetizione insieme a un ritardo di hedging più breve. Timeout brevi e aggressivi annullano le richieste prematuramente e attivano nuovi tentativi completi, eliminando il lavoro già in corso sul server. Un timeout più lungo consente il completamento della richiesta originale se è solo leggermente in ritardo.
  • Controllo del flusso e hedging lato client: l'hedging della pubblicazione non risolve i ritardi lato client, come la contesa della CPU o la mancanza di thread. Se la latenza di pubblicazione elevata è causata dalla coda dei messaggi nella memoria del client, l'utilizzo del controllo di flusso per gestire le dimensioni della coda può essere utile, anche se è necessario risolvere anche i vincoli delle risorse host.
  • Monitora le metriche di latenza e throughput di pubblicazione: utilizza i grafici delle metriche di Monitoring, ad esempio topic/send_request_latencies, per identificare i picchi di latenza di coda e determinare se l'hedging può essere utile. Tassi elevati di errori CANCELLED potrebbero indicare che le scadenze delle richieste sono configurate con un valore troppo basso. Se ottimizzata in modo efficace, la mitigazione della pubblicazione mantiene la velocità effettiva dei messaggi e il costo dei byte dell'argomento approssimativamente costanti anche durante la latenza della coda di pubblicazione.

Passaggi successivi

Per scoprire come configurare le opzioni di pubblicazione avanzate, consulta quanto segue: