Réessayer les requêtes

Les échecs de publication sont généralement dus à des goulots d'étranglement côté client, tels que des processeurs de service insuffisants, un mauvais état de thread ou un encombrement du réseau. La stratégie de nouvelle tentative de l'éditeur définit le nombre de fois où Pub/Sub tente de distribuer un message et la durée entre chaque tentative.

Ce document fournit des informations sur l'utilisation des requêtes de réessai 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 :

• Découvrez les sujets et le processus de publication.
• Créez un sujet.

Rôles requis

Pour obtenir les autorisations nécessaires pour réessayer d'envoyer des requêtes de message à un sujet, demandez à votre administrateur de vous accorder le rôle IAM Diffuseur 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 modifier des thèmes et des abonnements.

À propos des demandes de nouvelle tentative

Les paramètres de nouvelle tentative contrôlent la manière dont les bibliothèques clientes Pub/Sub relancent les requêtes de publication. Les bibliothèques clientes sont associées aux paramètres de nouvelle tentative suivants :

• Délai avant expiration de la requête initiale : délai avant l'arrêt d'une bibliothèque cliente en attente de l'exécution de la requête de publication initiale.
• Délai de nouvelle tentative : délai qui s'écoule entre le moment où une requête expire et le moment où une bibliothèque cliente effectue la nouvelle tentative.
• Délai avant expiration total : délai avant qu'une bibliothèque cliente n'arrête de relancer les requêtes de publication.

Pour relancer les requêtes de publication, le délai avant expiration de la requête initiale doit être inférieur au délai avant expiration total. Par exemple, si vous utilisez un intervalle exponentiel entre les tentatives, les bibliothèques clientes calculent le délai avant expiration de la requête et le délai de nouvelle tentative comme suit :

• Après chaque requête de publication, le délai avant expiration de la requête augmente en fonction du multiplicateur de délai avant expiration de la requête, jusqu'à atteindre le délai maximal avant expiration de la requête.
• Après chaque nouvelle tentative, le délai de nouvelle tentative augmente par le multiplicateur, jusqu'à atteindre le délai maximum de nouvelles tentatives.

Réessayer d'envoyer une demande de message

Lors du processus de publication, des échecs de publication temporaires ou permanents peuvent se produire. Pour les erreurs temporaires, vous n'avez généralement pas besoin d'effectuer d'action spéciale, car Pub/Sub relance automatiquement les messages.

Une erreur peut également se produire lorsqu'une opération de publication réussit, mais que le client de l'éditeur ne reçoit pas la réponse de publication à temps. Dans ce cas également, l'opération de publication est relancée. Par conséquent, vous pouvez avoir deux messages identiques avec des ID différents.

En cas d'erreurs persistantes, envisagez d'implémenter des actions appropriées en dehors du processus de publication pour éviter de surcharger Pub/Sub.

Lorsqu'une publication échoue, elle est automatiquement relancée, sauf en cas d'erreurs qui ne justifient pas de nouvelles tentatives. Cet exemple de code illustre la création d'un diffuseur avec des paramètres de nouvelle tentative personnalisés (notez que toutes les bibliothèques clientes ne sont pas compatibles avec les paramètres de nouvelle tentative. Consultez la documentation de référence de l'API pour le langage que vous avez choisi) :

namespace pubsub = ::google::cloud::pubsub;
using ::google::cloud::future;
using ::google::cloud::Options;
using ::google::cloud::StatusOr;
[](std::string project_id, std::string topic_id) {
  auto topic = pubsub::Topic(std::move(project_id), std::move(topic_id));
  // By default a publisher will retry for 60 seconds, with an initial backoff
  // of 100ms, a maximum backoff of 60 seconds, and the backoff will grow by
  // 30% after each attempt. This changes those defaults.
  auto publisher = pubsub::Publisher(pubsub::MakePublisherConnection(
      std::move(topic),
      Options{}
          .set<pubsub::RetryPolicyOption>(
              pubsub::LimitedTimeRetryPolicy(
                  /*maximum_duration=*/std::chrono::minutes(10))