Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Meilleures pratiques en matière de durabilité et de fiabilité des messages dans Amazon MQ pour RabbitMQ

Avant de passer votre application en production, suivez les bonnes pratiques suivantes pour éviter la perte de messages et la surutilisation des ressources.

Étape 1 : Utiliser des messages persistants et des files d'attente durables

Les messages persistants peuvent aider à prévenir la perte de données dans les situations où un agent se bloque ou redémarre. Les messages persistants sont écrits sur le disque dès leur arrivée. Cependant, contrairement aux files d'attente paresseuses, les messages persistants sont mis en cache à la fois dans la mémoire et dans le disque, sauf si l'agent a besoin de plus de mémoire. Dans les cas où plus de mémoire est nécessaire, les messages sont supprimés de la mémoire par le mécanisme d'agent RabbitMQ qui gère le stockage des messages sur disque, communément appelé couche de persistance.

Pour activer la persistance des messages, vous pouvez déclarer vos files d'attente comme durable et définissez le mode de remise des messages sur persistent. L'exemple suivant illustre l'utilisation de la bibliothèque client Java RabbitMQ pour déclarer une file d'attente durable. Lorsque vous travaillez avec AMQP 0-9-1, vous pouvez marquer les messages comme persistants en définissant le mode de livraison « 2 ».

boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);

Une fois que vous avez configuré votre file d'attente comme durable, vous pouvez envoyer un message persistant à votre file d'attente en définissant MessageProperties sur PERSISTENT_TEXT_PLAIN illustré dans l'exemple suivant.

import com.rabbitmq.client.MessageProperties;

channel.basicPublish("", "my_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

Étape 2 : Configuration des confirmations de l'éditeur et de l'accusé de réception du client

Le processus de confirmation de l'envoi d'un message au courtier est appelé confirmation de l'éditeur. L'éditeur confirme que votre application est informée lorsque les messages ont été stockés de manière fiable. Les confirmations de l'éditeur peuvent également aider à contrôler le taux de messages stockés auprès du courtier. Sans la confirmation de l'éditeur, il n'y a aucune confirmation qu'un message a été traité correctement, et votre courtier peut supprimer les messages qu'il ne peut pas traiter.

De même, lorsqu'une application cliente envoie une confirmation de livraison et de consommation de messages au courtier, on parle d'accusé de réception pour le consommateur. La confirmation et l'accusé de réception sont essentiels pour garantir la sécurité des données lorsque vous travaillez avec des courtiers RabbitMQ.

L'accusé de réception de livraison du consommateur est généralement configuré sur l'application client. Lorsque vous travaillez avec AMQP 0-9-1, l'accusé de réception peut être activé en configurant la méthode. basic.consume Les clients AMQP 0-9-1 peuvent également configurer les confirmations de l'éditeur en envoyant la méthode. confirm.select

En règle générale, l'accusé de réception de livraison est activé dans un canal. Par exemple, lorsque vous travaillez avec la bibliothèque client Java RabbitMQ, vous pouvez utiliser l'Channel#basicAck pour mettre en place une confirmation positive basic.ack comme illustré dans l'exemple suivant.

// this example assumes an existing channel instance

boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
     new DefaultConsumer(channel) {
         @Override
         public void handleDelivery(String consumerTag,
                                    Envelope envelope,
                                    AMQP.BasicProperties properties,
                                    byte[] body)
             throws IOException
         {
             long deliveryTag = envelope.getDeliveryTag();
             // positively acknowledge a single delivery, the message will
             // be discarded
             channel.basicAck(deliveryTag, false);
         }
     });

Vous pouvez configurer consumer_timeout pour détecter les cas où les consommateurs n'accusent pas réception des livraisons. Si le consommateur n'envoie pas d'accusé de réception dans le délai imparti, le canal sera fermé et vous recevrez un. PRECONDITION_FAILED Pour diagnostiquer l'erreur, utilisez l'UpdateConfigurationAPI pour augmenter la consumer_timeout valeur.

Étape 3 : Réduisez les files d'attente

Dans les déploiements en cluster, les files d'attente comportant un grand nombre de messages peuvent entraîner une surexploitation des ressources. Lorsqu'un agent est surutilisé, le redémarrage d'un agent Amazon MQ for RabbitMQ peut entraîner une dégradation supplémentaire des performances. En cas de redémarrage, les agents surexploités risquent de ne plus répondre dans l'état REBOOT_IN_PROGRESS.

Durant les fenêtres de maintenance, Amazon MQ effectue tous les travaux de maintenance un nœud à la fois pour s'assurer que l'agent reste opérationnel. Par conséquent, les files d'attente peuvent devoir se synchroniser à mesure que chaque nœud reprend l'opération. Pendant la synchronisation, les messages qui doivent être répliqués en miroirs sont chargés en mémoire à partir du volume Amazon Elastic Block Store (Amazon EBS) correspondant à traiter par lots. Le traitement des messages par lots permet aux files d'attente de se synchroniser plus rapidement.

Si les files d'attente sont courtes et que les messages sont petits, les files d'attente se synchronisent et reprennent le fonctionnement comme prévu. Toutefois, si la quantité de données dans un lot approche de la limite de mémoire du nœud, le nœud déclenche une alarme de mémoire élevée, mettant en pause la synchronisation de la file d'attente. Vous pouvez confirmer l'utilisation de la mémoire en comparant les métriques du nœud RabbitMemUsed et du nœud RabbitMqMemLimit broker dans CloudWatch. La synchronisation ne peut pas se terminer tant que les messages ne sont pas consommés ou supprimés, ou que le nombre de messages dans le lot est réduit.

Si la synchronisation des files d'attente est interrompue pour un déploiement en cluster, nous vous recommandons de consommer ou de supprimer des messages afin de réduire le nombre de messages dans les files d'attente. Une fois la profondeur de la file d'attente réduite et la synchronisation de la file d'attente terminée, l'état de l'agent passe à RUNNING. Pour résoudre une synchronisation de file d'attente interrompue, vous pouvez également appliquer une politique pour réduire la taille du lot de synchronisation des files d'attente.

Vous pouvez également définir des politiques de suppression automatique et de TTL afin de réduire de manière proactive l'utilisation des ressources et NACKs de limiter au maximum la communication avec les consommateurs. La mise en file d'attente de messages sur le courtier consomme beaucoup de ressources processeur, de sorte qu'un nombre élevé de messages peut affecter les performances du NACKs courtier.