ApsaraMQ for RocketMQ:Message sending retry and throttling

Processus de nouvelle tentative

Le SDK client intègre une logique de nouvelle tentative. Lorsqu'une requête d'envoi échoue, le SDK renvoie automatiquement le message ; aucun code de nouvelle tentative au niveau de l'application n'est nécessaire.

Définissez le nombre maximal de tentatives lors de l'initialisation du producteur. En cas d'échec d'une requête, le SDK effectue des tentatives jusqu'à la livraison du message ou jusqu'à l'atteinte de la limite de tentatives. Si la dernière tentative échoue, le SDK renvoie une erreur à votre application.

Le comportement des nouvelles tentatives varie selon le mode d'envoi :

Déclencheurs de nouvelles tentatives

Les nouvelles tentatives sont déclenchées par deux catégories d'échecs :

Échecs côté client

• Une exception réseau provoque un échec de connexion ou un délai d'expiration de la requête.

• Le broker redémarre ou fait l'objet d'un déploiement annulé, ce qui entraîne des échecs de connexion.

• Le broker fonctionne lentement, provoquant des délais d'expiration des requêtes.

Erreurs côté broker

• Erreur de logique système : une erreur de traitement interne sur le broker.

• Erreur de limitation de débit du système : le broker rejette la requête car il a dépassé sa capacité. Consultez la section Limitation de débit.

Intervalle de nouvelle tentative

L'intervalle entre les nouvelles tentatives dépend du type d'erreur :

Pour les erreurs de limitation de débit, le SDK utilise un backoff exponentiel avec les paramètres suivants :

L'algorithme de backoff fonctionne comme suit :

ConnectWithBackoff()
  current_backoff = INITIAL_BACKOFF
  current_deadline = now() + INITIAL_BACKOFF
  while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT)) != SUCCESS)
    SleepUntil(current_deadline)
    current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
    current_deadline = now() + current_backoff +
      UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)

Pour la spécification complète, consultez la documentation relative au backoff de connexion gRPC.

Comprendre le budget total de temps de nouvelle tentative

Le SDK expose une seule commande de nouvelle tentative : le nombre maximal de tentatives. En mode synchrone, le thread appelant reste bloqué pendant toute la séquence de nouvelles tentatives. Par conséquent, le temps de blocage total dépend de la relation entre le délai d'expiration par requête et le nombre maximal de tentatives :

Total blocking time (worst case) = max_retries x per_request_timeout + sum_of_backoff_delays

Pour les erreurs autres que la limitation de débit (nouvelle tentative immédiate), le délai de backoff est nul :

Total blocking time = max_retries x per_request_timeout

Pour les erreurs de limitation de débit, les délais de backoff s'accumulent de manière exponentielle. Par exemple, avec les paramètres par défaut et 5 nouvelles tentatives :

Évaluez conjointement votre délai d'expiration par requête et le nombre maximal de nouvelles tentatives afin d'éviter un blocage excessivement long du thread appelant en mode synchrone.

Gérer les messages ayant échoué après épuisement des nouvelles tentatives

Les nouvelles tentatives intégrées ne garantissent pas la livraison. Si toutes les tentatives échouent, le SDK renvoie une erreur. Interceptez cette erreur dans votre application et mettez en œuvre une stratégie de secours :

• Enregistrez le message ayant échoué dans un journal local ou un magasin de lettres mortes pour un retraitement ultérieur.

• Avertissez votre système de surveillance afin que vous puissiez enquêter sur la cause racine.

Gérer les messages en double résultant des nouvelles tentatives

Lorsqu'une requête d'envoi expire, le SDK ne peut pas déterminer si le broker a déjà reçu et stocké le message. Une nouvelle tentative peut générer un doublon sur le broker. Il s'agit d'un compromis fondamental inhérent aux systèmes de livraison « au moins une fois ».

Pour gérer les doublons, concevez vos consommateurs pour un traitement idempotent :

• Attribuez à chaque message une clé métier unique (telle qu'un ID de commande ou un ID de transaction).

• Avant le traitement, vérifiez si la clé a déjà été traitée.

• Utilisez des contraintes de base de données ou des caches de déduplication pour garantir l'unicité.

Déclencheurs de limitation de débit

La limitation de débit est déclenchée dans les scénarios suivants :

• Pic de pression de stockage : un groupe de consommateurs commence à consommer à partir du décalage maximal d'une file d'attente. Dans des scénarios tels que les déploiements commerciaux où un groupe de consommateurs doit commencer à consommer à un moment précis, la pression de stockage sur la file d'attente augmente brusquement. Pour plus d'informations, consultez Gestion de la progression des consommateurs.

• Accumulation de messages : lorsque les consommateurs ne peuvent pas suivre le rythme des messages entrants, les messages non consommés s'accumulent dans la file d'attente. Si l'accumulation dépasse le seuil, le broker déclenche la limitation de débit pour réduire la pression sur le système en aval.

Codes d'erreur et comportement de nouvelle tentative par type de client

Lorsque la limitation de débit est déclenchée, le code d'erreur et le comportement de nouvelle tentative dépendent du protocole de votre client.

Clients gRPC

Clients Remoting

Le comportement de nouvelle tentative pour les clients Remoting varie selon la version du SDK :

Si votre version du SDK n'effectue pas automatiquement de nouvelles tentatives en cas d'erreurs de limitation de débit, implémentez une logique de nouvelle tentative avec backoff exponentiel dans le code de votre application.

Prévenir et gérer la limitation de débit

Surveiller la capacité avant les pics de trafic

Utilisez les fonctionnalités d'observabilité d'ApsaraMQ for RocketMQ pour surveiller l'utilisation et la capacité du système. Avant les déploiements commerciaux ou les pics de trafic anticipés :

• Vérifiez que votre instance dispose de ressources suffisantes pour le trafic attendu.

• Contrôlez le retard des groupes de consommateurs pour identifier les risques d'accumulation.

• Mettez à l'échelle votre instance ou optimisez le débit des consommateurs si nécessaire.

Gérer la limitation de débit inattendue au moment de l'exécution

Si une limitation de débit survient de manière inattendue et que les nouvelles tentatives intégrées au SDK ne permettent pas de récupérer la situation :

• Routerez les requêtes vers un système de secours jusqu'à ce que la condition de limitation de débit soit levée.

• Enregistrez les événements de limitation de débit (recherchez le code d'erreur 530 / TOO_MANY_REQUESTS pour gRPC ou 215 / messages flow control pour Remoting) afin d'aider à diagnostiquer la cause racine.