Couverture de publication

Une latence de queue élevée lors de la publication de messages peut être causée par des retards réseau temporaires ou une lenteur temporaire côté serveur. La couverture de publication permet à un client éditeur Pub/Sub d'envoyer une requête de publication de sauvegarde (couverte) en parallèle si une requête en cours ne se termine pas dans un délai configuré, en utilisant la réponse qui est renvoyée en premier.

Ce document fournit des informations sur l'utilisation de la couverture de publication avec les messages publiés dans un sujet.

Avant de commencer

Avant de configurer le workflow de publication, assurez-vous d'avoir effectué les tâches suivantes :

Rôles requis

Pour obtenir les autorisations nécessaires pour envoyer des requêtes de publication hedgées à un sujet, demandez à votre administrateur de vous accorder le rôle IAM Éditeur Pub/Sub (roles/pubsub.publisher) sur le sujet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Vous devez disposer d'autorisations supplémentaires pour créer ou mettre à jour des sujets et des abonnements.

À propos de la couverture de publication

Les paramètres de couverture contrôlent comment et quand les bibliothèques clientes Pub/Sub envoient des requêtes de publication couvertes. La couverture de publication est désactivée par défaut. Lorsqu'elles sont activées, les bibliothèques clientes disposent des paramètres de couverture suivants :

  • Délai de couverture : durée pendant laquelle une bibliothèque cliente attend avant d'envoyer une requête de publication supplémentaire en parallèle si la requête précédente n'est pas terminée. La valeur par défaut est de 1 seconde, et la valeur configurée doit être comprise entre 100 millisecondes et 10 secondes.
  • Nombre maximal de jetons : nombre maximal de jetons qu'une bibliothèque cliente peut accumuler pour envoyer des requêtes de publication de couverture. Chaque requête de publication couverte consomme un jeton. La valeur par défaut est 50 et la valeur configurée doit être comprise entre 1 et 250.
  • Taux de remplissage : nombre de jetons ajoutés pour chaque requête de publication réussie. Cette valeur contrôle la fraction maximale de requêtes de publication pouvant être couvertes au fil du temps. Par exemple, un taux de remplissage de 0,1 permet de couvrir jusqu'à 10 % des requêtes de publication. La valeur par défaut est 0,1, et la valeur configurée doit être comprise entre 0,001 et 0,2.

Pour couvrir les requêtes de publication, le délai de couverture doit être inférieur au délai avant expiration de la requête initiale et au délai avant expiration total dans les paramètres de nouvelle tentative du diffuseur. Sinon, l'initialisation du client éditeur échouera. Lorsque la couverture de publication est activée, la bibliothèque cliente envoie les requêtes de publication comme suit :

  • Si une requête de publication en cours ne se termine pas dans le délai de couverture et qu'au moins un jeton est disponible, la bibliothèque cliente consomme un jeton et envoie une requête de publication supplémentaire pour le même lot de messages en parallèle, tout en conservant la requête initiale en attente.
  • Si aucune des requêtes en cours n'aboutit après un autre délai de couverture, la bibliothèque cliente continue d'envoyer des requêtes de couverture supplémentaires à intervalles réguliers, tant que des jetons restent disponibles et que le délai avant expiration total n'est pas écoulé.
  • Dès qu'une requête de publication en cours pour le lot aboutit, la bibliothèque cliente termine l'opération de publication, annule toutes les tentatives en cours restantes pour ce lot et augmente le nombre de jetons disponibles en fonction du taux de remplissage, jusqu'au nombre maximal de jetons.

Couvrir une requête de publication

Contrairement aux requêtes de nouvelle tentative, qui attendent qu'une requête de publication en cours échoue ou expire, la couverture de publication maintient la requête initiale en attente tout en envoyant une requête couverte simultanée. Cela réduit la latence de queue sans annuler prématurément les requêtes qui sont sur le point de réussir.

Étant donné que plusieurs requêtes pour le même lot de messages peuvent être en cours simultanément, plusieurs tentatives peuvent aboutir avant que les tentatives restantes ne soient annulées, car l'annulation de la requête de publication est effectuée au mieux. Par conséquent, vous pouvez recevoir des messages en double avec des ID de message différents, ce qui peut augmenter le trafic réseau client et les coûts Pub/Sub liés à la publication et à la distribution de ces doublons. Consultez Résoudre les problèmes de messages en double, renvoyés ou manquants pour obtenir des conseils sur la gestion des messages en double.

Si une dégradation du service entraîne une augmentation prolongée de la latence ou des erreurs, les paramètres de jetons maximum et de taux de remplissage empêchent les taux de publication couverts de devenir trop élevés. Étant donné que les jetons ne sont ajoutés que lorsque les requêtes de publication aboutissent, une lenteur ou des erreurs prolongées épuisent rapidement les jetons disponibles et limitent automatiquement les requêtes de couverture.

Cet exemple de code montre comment créer un éditeur avec des paramètres de couverture personnalisés. Toutes les bibliothèques clientes ne sont pas compatibles avec la couverture de publication. Consultez la documentation de référence de l'API pour le langage de votre choix.

Java

Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Java qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Java 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);
      }
    }
  }
}

Publier une couverture avec des clés de tri

La couverture de publication ne peut pas être utilisée avec l'ordre des messages. Étant donné que la couverture de publication envoie des requêtes de publication simultanées pour le même lot de messages, le service Pub/Sub peut recevoir et traiter ces requêtes dans le désordre. Si vous activez à la fois le tri des messages et la couverture de publication sur un client éditeur, la création de l'éditeur échoue et génère une erreur.

Conseils et bonnes pratiques

Tenez compte des bonnes pratiques suivantes lorsque vous configurez la couverture de publication :

  • Utiliser la couverture pour la latence de queue temporaire : la couverture de publication est conçue pour lisser les pics de latence de courte durée causés par des retards réseau temporaires ou de brèves lenteurs côté serveur. Ne comptez pas sur la couverture pour atténuer les pannes prolongées ou les erreurs persistantes.
  • Couverture avec des règles de nouvelle tentative : définissez un délai avant expiration de la requête initiale plus long dans vos paramètres de nouvelle tentative, ainsi qu'un délai de couverture plus court. Les délais avant expiration courts et agressifs annulent les requêtes prématurément et déclenchent de nouvelles tentatives complètes, ce qui annule le travail déjà en cours sur le serveur. Un délai avant expiration plus long permet à la requête d'origine de se terminer si elle n'est que légèrement retardée.
  • Contrôle de flux et couverture côté client : la couverture de publication ne résout pas les retards côté client, tels que les conflits de processeur ou l'insuffisance de threads. Si la latence de publication élevée est due à la mise en file d'attente des messages dans la mémoire du client, l'utilisation du contrôle de flux pour gérer la taille des files d'attente peut être utile, même si les contraintes de ressources hôtes doivent également être prises en compte.
  • Surveillez les métriques de latence et de débit de publication : utilisez des graphiques de métriques Monitoring tels que topic/send_request_latencies pour identifier les pics de latence de queue et déterminer si la couverture peut être utile. Des taux élevés d'erreurs CANCELLED peuvent indiquer que les délais de vos requêtes sont configurés trop bas. Lorsqu'il est réglé efficacement, le hedging de publication maintient le débit des messages et le coût des octets du sujet à un niveau approximativement constant, même pendant la latence de publication.

Étapes suivantes

Pour savoir comment configurer les options de publication avancées, consultez les ressources suivantes :