Tous les produits
Search

Ce produit

    ApsaraMQ for RocketMQ:Messages transactionnels

    Centre de documentation

    ApsaraMQ for RocketMQ:Messages transactionnels

    Dernière mise à jour :Aug 09, 2026

    ApsaraMQ for RocketMQ prend en charge les messages transactionnels distribués. Les messages transactionnels s'appliquent aux scénarios nécessitant une cohérence à terme. Cette rubrique décrit les concepts, les avantages, les cas d'utilisation, le processus d'interaction, les notes d'utilisation et des exemples de code des messages transactionnels ApsaraMQ for RocketMQ.

    Termes

    • Message transactionnel : ApsaraMQ for RocketMQ fournit une fonctionnalité de traitement des transactions distribuées similaire à X/Open XA afin de garantir la cohérence des transactions dans ApsaraMQ for RocketMQ.

    • Demi-message : un demi-message est un message qui ne peut pas être distribué temporairement. Si le producteur envoie un message au broker ApsaraMQ for RocketMQ, mais que le broker ne reçoit pas le deuxième accusé de réception (ACK) du producteur, le message est marqué comme « temporairement non distribuable ». Un message dans cet état est appelé demi-message.ApsaraMQ for RocketMQ

    • Vérification de l'état du message : le deuxième ACK d'un message transactionnel peut être perdu en cas de problème de connexion réseau temporaire ou si l'application producteur redémarre. Lorsque le broker ApsaraMQ for RocketMQ constate qu'un message reste un demi-message pendant une période prolongée, il envoie une requête au producteur pour vérifier si l'état final du message est Commit ou Rollback.

    Avantages

    ApsaraMQ for RocketMQ utilise des messages transactionnels distribués pour découpler les applications et garantir la cohérence finale des données. Les transactions volumineuses traditionnelles peuvent être divisées en transactions plus petites, ce qui améliore l'efficacité. Cette approche garantit également la disponibilité du système central lorsqu'une exception se produit dans une application. Si une application ne parvient pas à recevoir des messages, vous pouvez compléter ou corriger les données uniquement pour cette application sans avoir à annuler tous les messages.

    Cas d'utilisation

    Lorsque les utilisateurs ajoutent des articles à leur panier sur des applications de commerce électronique, le système de panier et le système de transaction sont impliqués. Les messages transactionnels distribués permettent un traitement asynchrone, garantissant ainsi la cohérence à terme entre les deux systèmes. Dans ce scénario, le système de transaction est crucial et la fonctionnalité de traitement des transactions distribuées doit s'assurer que les commandes sont passées avec succès. Le système de panier peut s'abonner uniquement aux topics liés aux commandes depuis ApsaraMQ for RocketMQ puis exécuter les transactions correspondantes. De cette manière, la fonctionnalité de traitement des transactions distribuées garantit la cohérence à terme entre les deux systèmes.

    Processus d'interaction

    La figure suivante illustre le processus d'interaction des messages transactionnels. Transactional messages

    La procédure d'envoi d'un message transactionnel comprend les étapes suivantes :

    1. Un producteur envoie un demi-message au broker ApsaraMQ for RocketMQ.

    2. Le broker ApsaraMQ for RocketMQ convertit le message en message persistant et envoie un ACK au producteur pour confirmer la réception du message. À ce stade, le message est un demi-message.

    3. Le producteur exécute une transaction locale.

    4. Le producteur envoie un deuxième ACK au broker pour soumettre le résultat de l'exécution de la transaction locale. Le résultat de l'exécution peut être Commit ou Rollback.

      • Si l'état du message reçu par le broker est Commit, le broker marque le demi-message comme distribuable et le livre au consommateur.

      • Si l'état du message reçu par le broker est Rollback, le broker annule la transaction et ne distribue pas le demi-message au consommateur.

    5. La connexion réseau est interrompue ou l'application producteur redémarre. Dans ce cas, si le broker ne reçoit pas de deuxième ACK ou si l'état du demi-message est Unknown, le broker attend un certain temps et envoie une requête à un producteur du cluster de producteurs pour interroger l'état du demi-message.

    Les étapes suivantes fournissent les instructions pour vérifier l'état d'un message transactionnel :

    1. Après avoir reçu la requête, le producteur vérifie le résultat de l'exécution de la transaction locale correspondant au demi-message.

    2. Le producteur envoie un autre ACK au broker ApsaraMQ for RocketMQ en fonction du résultat de l'exécution de la transaction locale. Ensuite, le broker traite le demi-message en suivant l'étape 4.

    Notes d'utilisation

    Règles d'envoi des messages

    • Lorsqu'un producteur envoie un message au broker et exécute la transaction locale, l'un des états suivants est renvoyé dans la méthode execute :

      • TransactionStatus.CommitTransaction : la transaction est validée. Le consommateur peut consommer le message.

      • TransactionStatus.RollbackTransaction : la transaction est annulée. Le message est ignoré et ne peut pas être consommé.

      • TransactionStatus.Unknow : la transaction est dans un état inconnu. Après un certain temps, le broker ApsaraMQ for RocketMQ envoie une requête pour vérifier l'état du message.

    • Vous devez spécifier la classe d'implémentation de la méthode LocalTransactionChecker lors de la création d'un producteur de messages transactionnels en appelant ONSFactory.createTransactionProducer. Ainsi, le broker peut vérifier l'état des messages transactionnels en cas d'exceptions.

    • Règles de vérification de l'état du message : après l'exécution de la transaction locale, le broker ApsaraMQ for RocketMQ reçoit un ACK indiquant que le résultat de l'exécution est TransactionStatus.Unknow, ou le producteur se termine de manière inattendue et ne soumet pas le résultat de l'exécution de la transaction locale. Dans ce cas, le broker ApsaraMQ for RocketMQ envoie une requête au producteur pour vérifier le résultat de l'exécution de la transaction locale. Si le broker ne parvient pas à obtenir le résultat, il envoie la requête à un intervalle spécifié.

      • Intervalle de vérification : par défaut, le broker envoie une requête toutes les 30 secondes pendant 12 heures pour vérifier l'état d'un demi-message.

      • Temps d'attente avant la vérification de l'état d'un demi-message nouvellement reçu : ce paramètre est défini par l'utilisateur. Lorsque le broker doit initier la vérification périodique de l'état du message, mais que le temps d'attente avant la vérification de l'état d'un demi-message nouvellement reçu n'est pas écoulé, le broker ne vérifie pas l'état du message.

        L'exemple suivant utilise Java. Le paramétrage indique que le temps d'attente avant la vérification de l'état d'un demi-message nouvellement reçu est de 60 secondes.

        Message message = new Message();
message.putUserProperties(PropertyKeyConst.CheckImmunityTimeInSeconds,"60");
        Remarque

        Toutefois, le temps réel avant la vérification de l'état du message nouvellement reçu peut dépasser le temps prévu de 0 à 30 secondes. Cela s'explique par le fait que le broker vérifie l'état du message à un intervalle par défaut.

        Par exemple, si vous définissez le temps d'attente avant la vérification de l'état d'un message nouvellement reçu à 60 secondes, mais que le broker initie la vérification périodique à la 58e seconde après la réception d'un nouveau demi-message, le message n'est pas vérifié. Après 30 secondes, le broker initie une autre vérification périodique à la 88e seconde après la réception du nouveau demi-message. Dans ce cas, le message est vérifié. Le moment de la vérification du message intervient 28 secondes plus tard que l'heure prévue.

    Règles de consommation des messages

    • Les messages transactionnels ne peuvent pas partager d'ID de groupe avec des messages d'autres types. La différence entre les messages transactionnels et les autres types de messages réside dans le fait que les messages transactionnels fournissent un mécanisme de vérification de l'état des messages. Le broker ApsaraMQ for RocketMQ peut interroger les producteurs de messages par ID de groupe.

    Exemples de code

    Les exemples de code dans différents langages de programmation pour l'envoi et l'abonnement à des messages transactionnels sont fournis dans les rubriques suivantes :