ApsaraMQ for RocketMQ:Nouvelle tentative de consommation

Comprendre le mécanisme d'accusé de réception des messages et les politiques de nouvelle tentative de consommation de ApsaraMQ for RocketMQ peut vous aider à analyser les problèmes suivants :

• Comment garantir un traitement complet des messages : connaître la politique de nouvelle tentative vous aide à concevoir une logique de consommateur qui garantit que chaque message est entièrement traité, empêchant ainsi l'ignorance des messages et l'incohérence des états métier.

• Comment récupérer l'état des messages lors de pannes système : cela clarifie comment les états des messages en cours sont restaurés lors d'anomalies système (telles que des pannes) et si une incohérence d'état peut se produire.

Déclencheurs de nouvelle tentative

• Échec de consommation, y compris le retour d'un statut d'échec ou le lancement d'une exception inattendue.

• Délai d'expiration du traitement des messages, y compris le délai d'expiration de la file d'attente dans PushConsumer.

Principaux comportements de nouvelle tentative

• Machine d'état de nouvelle tentative : contrôle les états des messages et les transitions lors de la nouvelle tentative.

• Intervalle de nouvelle tentative : le temps entre un échec de consommation (ou un délai d'expiration) et le moment où le message devient disponible pour une reconsommation.

• Nombre maximal de nouvelles tentatives : le nombre maximal de fois où un message peut faire l'objet d'une nouvelle tentative.

Différences de politique de nouvelle tentative de message

Pour les politiques de nouvelle tentative détaillées, consultez Politique de nouvelle tentative de consommation PushConsumer et Politique de nouvelle tentative de consommation SimpleConsumer.

Machine d'état de nouvelle tentative

Exemple : dans le schéma ci-dessus, supposons qu'un message reste en état Ready pendant 5 secondes et prend 6 secondes à traiter.

Chaque cycle de nouvelle tentative suit la séquence Ready → Inflight → WaitingRetry. L'intervalle de nouvelle tentative correspond au temps entre un échec (ou un délai d'expiration) et le moment où le message redevient Ready. Le temps réel entre deux tentatives de consommation inclut également le temps de traitement et la durée en état Ready. Par exemple :

• À 0 s, le message passe en état Ready.

• En raison de la vitesse de traitement du consommateur, la consommation commence à 5 s. Après 6 secondes (à 11 s), une exception se produit et le client renvoie un échec.

• La nouvelle tentative ne peut pas commencer immédiatement ; elle doit attendre l'intervalle de nouvelle tentative.

• À 21 s, le message redevient Ready.

• Le client commence à reconsommer 5 secondes plus tard.

Ainsi, l'intervalle réel entre deux tentatives de consommation est : temps de traitement + intervalle de nouvelle tentative + durée en état Ready = 21 s.

Intervalles de nouvelle tentative

• Messages non ordonnés (messages non séquencés) : l'intervalle de nouvelle tentative utilise une approche temporelle par paliers, comme suit :

  |
  **Tentative de nouvelle tentative**
  |
  **Intervalle de nouvelle tentative**
  |
  **Tentative de nouvelle tentative**
  |
  **Intervalle de nouvelle tentative**
  | | --- | --- | --- | --- | |
  1
  |
  10 secondes
  |
  9
  |
  7 minutes
  | |
  2
  |
  30 secondes
  |
  10
  |
  8 minutes
  | |
  3
  |
  1 minute
  |
  11
  |
  9 minutes
  | |
  4
  |
  2 minutes
  |
  12
  |
  10 minutes
  | |
  5
  |
  3 minutes
  |
  13
  |
  20 minutes
  | |
  6
  |
  4 minutes
  |
  14
  |
  30 minutes
  | |
  7
  |
  5 minutes
  |
  15
  |
  1 heure
  | |
  8
  |
  6 minutes
  |
  16
  |
  2 heures
  |
  Remarque

  Si les tentatives de nouvelle tentative dépassent 16, toutes les nouvelles tentatives suivantes utilisent un intervalle de 2 heures.

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• Messages ordonnés : utilisez un intervalle de nouvelle tentative fixe. Pour les valeurs spécifiques, consultez Limites des paramètres.

Nombre maximal de nouvelles tentatives

• Valeur par défaut : 16.

• Maximum : 1 000.

Pour PushConsumer, le nombre maximal de nouvelles tentatives est contrôlé par les métadonnées du groupe de consommateurs. Pour le modifier, consultez Modifier le nombre maximal de nouvelles tentatives.

Par exemple, si le nombre maximal de nouvelles tentatives est de 3, le message est livré jusqu'à 4 fois : une fois initialement et trois fois via nouvelle tentative.

Exemple d'utilisation

Pour déclencher une nouvelle tentative dans PushConsumer, il suffit de renvoyer un code d'état d'échec de consommation. Les exceptions inattendues sont automatiquement interceptées par le SDK.

SimpleConsumer simpleConsumer = null;
        // Consumption example: Use PushConsumer to consume normal messages. Return an error on failure to trigger retry.
        MessageListener messageListener = new MessageListener() {
            @Override
            public ConsumeResult consume(MessageView messageView) {
                System.out.println(messageView);
                // Return FAILURE to trigger automatic retry until the maximum retry count is reached.
                return ConsumeResult.FAILURE;
            }
        };
            

Consulter les journaux de nouvelle tentative de consommation

Pour les messages ordonnés, PushConsumer effectue les nouvelles tentatives côté client. Le serveur ne peut pas accéder aux journaux de nouvelle tentative détaillés. Si la trace des messages indique un échec de livraison pour un message ordonné, vérifiez les journaux du client consommateur pour obtenir le nombre maximal de nouvelles tentatives et les informations sur le client.

Pour le chemin d'accès aux journaux du client, consultez Configuration des journaux.

Recherchez ces mots-clés dans les journaux du client pour localiser rapidement les détails des échecs de consommation :

Message listener raised an exception while consuming messages
Failed to consume fifo message finally, run out of attempt times

Machine d'état de nouvelle tentative

Contrairement à PushConsumer, SimpleConsumer utilise un intervalle de nouvelle tentative préalloué. Lors de la récupération d'un message, le consommateur définit un paramètre InvisibleDuration — le temps de traitement maximal autorisé. En cas d'échec, le prochain intervalle de nouvelle tentative réutilise cette valeur sans configuration supplémentaire.

Étant donné que InvisibleDuration est préallouée, elle peut différer considérablement du temps de traitement réel. Vous pouvez la modifier via l'API.

Par exemple, si vous définissez initialement le temps de traitement à 20 ms, mais que le traitement réel dépasse cette durée, augmentez InvisibleDuration pour éviter des nouvelles tentatives prématurées.

Comme illustré ci-dessous, la nouvelle InvisibleDuration prend effet immédiatement — redémarrant le minuteur d'invisibilité à partir du moment de l'appel API.

Intervalle de nouvelle tentative

Intervalle de nouvelle tentative = InvisibleDuration − Temps de traitement réel

SimpleConsumer contrôle les intervalles de nouvelle tentative via InvisibleDuration. Par exemple, si InvisibleDuration est de 30 ms et que le traitement échoue après 10 ms, la prochaine nouvelle tentative aura lieu après 20 ms. Si le traitement ne se termine pas dans les 30 ms et qu'aucun résultat n'est renvoyé, le message expire et fait l'objet d'une nouvelle tentative immédiatement (intervalle de 0 ms).

Nombre maximal de nouvelles tentatives

• Valeur par défaut : 16.

• Maximum : 1 000.

Pour SimpleConsumer, le nombre maximal de nouvelles tentatives est contrôlé par les métadonnées du groupe de consommateurs lors de la création. Pour le modifier, consultez Modifier le nombre maximal de nouvelles tentatives.

Par exemple, si le nombre maximal de nouvelles tentatives est de 3, le message est livré jusqu'à 4 fois : une fois initialement et trois fois via nouvelle tentative.

Exemple d'utilisation

Pour déclencher une nouvelle tentative dans SimpleConsumer, il suffit d'attendre.

 // Consumption example: Use SimpleConsumer to consume normal messages. To trigger retry, remain silent and let the message time out. The server will automatically retry.
        List<MessageView> messageViewList = null;
        try {
            messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
            messageViewList.forEach(messageView -> {
                System.out.println(messageView);
                // On failure, ignore the message. It will become visible again and be retried.
            });
        } catch (ClientException e) {
            // If pull fails due to throttling or other system issues, retry the receive request.
            e.printStackTrace();
        }

SDK gRPC

• Modifier via OpenAPI : Mettre à jour le groupe de consommateurs

• Modifier via console :

  Pour accéder au paramètre :

  1. Sur la page Instances, cliquez sur le nom de l'instance cible.

  2. Dans le volet de navigation de gauche, cliquez sur Groups. Sur la page Groups, cliquez sur Create Group.

  Dans la boîte de dialogue Create Group, définissez Group ID (1 à 60 caractères), Delivery Order (Concurrent Delivery ou Ordered Delivery) et Description. Développez Advanced Settings pour configurer la politique de nouvelle tentative en tant que Exponential Backoff, définissez Maximum Retry Count (par défaut : 16) et activez/désactivez Retain Dead-letter Messages (par défaut : désactivé ; si désactivé, les messages dépassant le nombre de nouvelles tentatives sont rejetés).

SDK Remoting

• Modifier via le paramètre du SDK Remoting : définissez la propriété maxReconsumeTimes du consommateur.

Effectuez des nouvelles tentatives de manière raisonnable — évitez d'utiliser la nouvelle tentative pour la limitation de débit

Comme indiqué dans Scénarios, la nouvelle tentative de message convient aux échecs métier rares, et non aux échecs systémiques ou continus tels que la limitation de débit.

• Exemple incorrect :

  Si le taux de consommation déclenche une limitation, renvoyez un échec et attendez la nouvelle tentative.

• Exemple correct :

  Si le taux de consommation déclenche une limitation, retardez la récupération des messages et consommez-les plus tard.

Comment définir le délai d'expiration de la consommation des messages ?

consumer.setConsumeTimeout(15); // Unit: minutes. Range: 1–180 minutes