Tous les produits
Search
Centre de documentation

:How to implement reconnection retry mechanism in clients

Dernière mise à jour :Aug 10, 2026

Pour garantir la fiabilité des interactions en cas d'instabilités réseau ou d'anomalies serveur, les clients Simple Message Queue (SMQ, anciennement MNS) appliquent des politiques de fiabilité tant pour le producteur que pour le consommateur.

Producteur : mécanisme de nouvelle tentative

  • Types d'exceptions et déclenchement des nouvelles tentatives

    • Types d'exceptions : identifiez et catégorisez les exceptions client (MNS ClientException, telles que les délais d'attente réseau ou les erreurs de limitation de débit) et les exceptions serveur (ServerException). Distinguez les erreurs éligibles à une nouvelle tentative (par exemple, codes d'erreur 5xx ou instabilités réseau) de celles qui ne le sont pas (par exemple, ressource inexistante, erreur QueueNotExist).

    • Nouvelles tentatives côté client : implémentez une logique de nouvelle tentative directement dans votre code métier pour renvoyer les messages selon vos besoins spécifiques.

  • Politique de temporisation exponentielle (backoff)

    • Nous vous recommandons d'implémenter une politique de temporisation exponentielle (par exemple, départ à 1 seconde, plafonné à 60 secondes), combinée à une gigue aléatoire. Cette approche évite les surcharges dues à un excès de nouvelles tentatives au niveau du cluster.

Consommateur : mécanisme de nouvelle tentative

  • Producteur : nouvelle tentative automatique

    • En cas d'échec de la consommation (par exemple, messages non acquittés explicitement ou dépassement du délai de consommation), SMQ redistribue automatiquement les messages en se fondant sur le délai de visibilité des files d'attente lorsque le client récupère de nouveaux messages.

  • Consommateur : conception idempotente

    • Concevez une logique métier naturellement idempotente (par exemple, déduplication via une clé de base de données unique) ou vérifiez si le message a déjà été consommé en vous appuyant sur l'identifiant unique du message MessageId associé à l'état du service.

  • Gestion des exceptions

    • En cas d'exception lors de la consommation des messages, n'envoyez pas d'accusé de réception (ACK). Laissez SMQ redistribuer le message jusqu'à sa consommation réussie, puis appelez l'opération DeleteMessage pour le supprimer.

Références

Pour des exemples de code en Java, consultez la rubrique Recevoir des messages depuis une file d'attente.